Veritaban\u0131 sorgular\u0131nda performans kritik \u00f6neme sahiptir. \u00d6zellikle b\u00fcy\u00fck veri setlerinde, tekrarlayan veya benzersiz de\u011ferleri sayma\/listeleme i\u015flemleri ciddi performans darbo\u011fazlar\u0131na yol a\u00e7abilir. AWS DocumentDB’nin 0.116 s\u00fcr\u00fcm\u00fcnde tan\u0131t\u0131lan G\u00fcn\u00fcm\u00fcz uygulamalar\u0131, kullan\u0131c\u0131lar\u0131n eylemlerini, \u00fcr\u00fcn tercihlerini, co\u011frafi konumlar\u0131n\u0131 ve daha pek \u00e7ok dinami\u011fi s\u00fcrekli olarak kaydediyor. Bu veriler, i\u015f zekas\u0131 analizleri, raporlamalar, ki\u015fiselle\u015ftirilmi\u015f \u00f6neriler ve hatta temel i\u015flevler i\u00e7in hayati \u00f6nem ta\u015f\u0131yor. Ancak, bu kay\u0131tlar genellikle ham ve tekrarlayan bilgiler i\u00e7erir. \u00d6rne\u011fin, bir e-ticaret platformunda, ayn\u0131 kullan\u0131c\u0131n\u0131n ayn\u0131 \u00fcr\u00fcne defalarca bakmas\u0131 olduk\u00e7a yayg\u0131n bir durumdur. Bir analiz yaparken, “Bug\u00fcn ka\u00e7 farkl\u0131 kullan\u0131c\u0131 \u00fcr\u00fcnlerimize g\u00f6z att\u0131?” sorusunu yan\u0131tlamak istedi\u011fimizde, her bir g\u00f6r\u00fcnt\u00fclemeyi de\u011fil, yaln\u0131zca benzersiz kullan\u0131c\u0131 kimliklerini saymam\u0131z gerekir. \u0130\u015fte bu noktada, Geleneksel y\u00f6ntemlerde, bir veritaban\u0131nda belirli bir alana g\u00f6re benzersiz de\u011ferleri elde etmek i\u00e7in genellikle iki ana yakla\u015f\u0131m izlenirdi: ya t\u00fcm veriyi belle\u011fe y\u00fckleyip uygulama katman\u0131nda benzersizle\u015ftirme yapmak ya da veritaban\u0131n\u0131n daha karma\u015f\u0131k ve bazen daha az performansl\u0131 operasyonlar\u0131n\u0131 kullanmak. \u0130lk y\u00f6ntem, b\u00fcy\u00fck veri setlerinde bellek yetersizli\u011fine yol a\u00e7abilirken, ikinci y\u00f6ntem de sorgu karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 art\u0131rabilir ve yine de istenen performans\u0131 vermeyebilir. Bu t\u00fcr zorluklar, geli\u015ftiricilerin veritaban\u0131 operasyonlar\u0131n\u0131 optimize etmek i\u00e7in s\u00fcrekli yeni yollar aramas\u0131na neden oluyordu. \u00d6zellikle MongoDB ile uyumlu \u00e7al\u0131\u015fan DocumentDB gibi NoSQL veritabanlar\u0131nda, bu t\u00fcr toplama (aggregation) i\u015flemleri s\u0131k\u00e7a kullan\u0131l\u0131r ve performanslar\u0131 do\u011frudan kullan\u0131c\u0131 deneyimini etkiler.<\/p>\n DocumentDB’nin 0.116 s\u00fcr\u00fcm\u00fcyle gelen AWS DocumentDB, MongoDB 3.6 API ile uyumlu bir NoSQL veritaban\u0131 hizmetidir. MongoDB’nin g\u00fc\u00e7l\u00fc toplama (aggregation) \u00e7er\u00e7evesini destekler. Bu \u00e7er\u00e7eve, verileri i\u015flemek, d\u00f6n\u00fc\u015ft\u00fcrmek ve \u00f6zetlemek i\u00e7in g\u00fc\u00e7l\u00fc bir ara\u00e7 setidir. \u015eimdi, benzersiz tarama (distinct scan) kavram\u0131na odaklanal\u0131m. DocumentDB 0.116 \u00f6ncesinde, bir DocumentDB 0.116 s\u00fcr\u00fcm\u00fcyle birlikte, Bu iyile\u015ftirmenin temelinde, veritaban\u0131 motorunun dahili veri yap\u0131lar\u0131 ve algoritmalar\u0131ndaki g\u00fcncellemeler yat\u0131yor. Motor, grupland\u0131rma anahtarlar\u0131n\u0131 ve ilgili de\u011ferleri daha ak\u0131ll\u0131ca \u00f6nbelle\u011fe alabilir veya daha h\u0131zl\u0131 eri\u015fim sa\u011flayan veri yap\u0131lar\u0131 kullanabilir. Bu sayede, ayn\u0131 de\u011feri i\u015flemek i\u00e7in harcanan CPU ve bellek kaynaklar\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde azal\u0131r. Sonu\u00e7 olarak, geli\u015ftiriciler, daha karma\u015f\u0131k sorgular yazmak zorunda kalmadan, daha h\u0131zl\u0131 ve daha verimli toplama i\u015flemleri ger\u00e7ekle\u015ftirebilirler. Bu, \u00f6zellikle ger\u00e7ek zamanl\u0131 analizler, raporlama sistemleri ve kullan\u0131c\u0131 davran\u0131\u015flar\u0131n\u0131 izleyen uygulamalar i\u00e7in b\u00fcy\u00fck bir kazan\u0131md\u0131r.<\/p>\n Bir e-ticaret platformu d\u00fc\u015f\u00fcnelim. Her kullan\u0131c\u0131 etkile\u015fimi (\u00fcr\u00fcn g\u00f6r\u00fcnt\u00fcleme, sepete ekleme, sat\u0131n alma) bir belge olarak veritaban\u0131na kaydediliyor. Bu belgeler, kullan\u0131c\u0131n\u0131n kimli\u011fi (userID), \u00fcr\u00fcn kimli\u011fi (productID), zaman damgas\u0131 (timestamp) ve di\u011fer detaylar\u0131 i\u00e7eriyor. Platform y\u00f6neticileri, g\u00fcnl\u00fck olarak ka\u00e7 farkl\u0131<\/strong> kullan\u0131c\u0131n\u0131n siteyi ziyaret etti\u011fini bilmek istiyor. Bu, pazarlama kampanyalar\u0131n\u0131n etkinli\u011fini \u00f6l\u00e7mek ve kullan\u0131c\u0131 trafi\u011fini anlamak i\u00e7in kritik bir metriktir.<\/p>\n Eski DocumentDB s\u00fcr\u00fcmlerinde veya benzeri sistemlerde, bu sorguyu \u00e7al\u0131\u015ft\u0131rmak \u015f\u00f6yle g\u00f6r\u00fcnebilirdi:<\/p>\n Yukar\u0131daki sorguda, ilk DocumentDB 0.116’da ise bu t\u00fcr i\u015flemler, Bu sorguda, Bu iyile\u015ftirme, sadece ziyaret\u00e7i say\u0131s\u0131n\u0131 bulmakla kalmaz, ayn\u0131 zamanda daha karma\u015f\u0131k analizler i\u00e7in de kap\u0131 aralar. \u00d6rne\u011fin, “En \u00e7ok hangi \u00fcr\u00fcnler farkl\u0131 kullan\u0131c\u0131lar taraf\u0131ndan g\u00f6r\u00fcnt\u00fclendi?” veya “Hangi kullan\u0131c\u0131lar en \u00e7ok say\u0131da farkl\u0131 \u00fcr\u00fcn\u00fc g\u00f6r\u00fcnt\u00fcledi?” gibi sorulara daha h\u0131zl\u0131 yan\u0131tlar bulmak m\u00fcmk\u00fcn hale gelir. Bu t\u00fcr analizler, stok y\u00f6netimi, \u00fcr\u00fcn \u00f6neri sistemleri ve pazarlama stratejilerinin belirlenmesinde kritik rol oynar.<\/p>\n DocumentDB 0.116’daki Optimizasyon \u00f6ncesinde, bir Bu s\u00fcre\u00e7te, 5. ad\u0131mda yap\u0131lan “kontrol et ve ekle” i\u015flemi, \u00f6zellikle diziler b\u00fcy\u00fcd\u00fck\u00e7e veya ayn\u0131 de\u011ferler tekrar tekrar gelirse, hesaplama maliyeti y\u00fcksek olabilir. Veritaban\u0131 motorunun, her bir yeni \u00f6\u011fe i\u00e7in dizinin tamam\u0131n\u0131 veya b\u00fcy\u00fck bir k\u0131sm\u0131n\u0131 taramas\u0131 gerekebilir.<\/p>\n DocumentDB 0.116’daki optimizasyonlar, bu s\u00fcreci daha verimli hale getirir. Bu optimizasyonlar genellikle \u015fu \u015fekillerde ger\u00e7ekle\u015fir:<\/p>\n \u00d6zetle, DocumentDB 0.116, Yeni bir \u00f6zellik kullan\u0131ma sunuldu\u011funda, en \u00f6nemli ad\u0131mlardan biri, bu \u00f6zelli\u011fin ger\u00e7ek d\u00fcnyadaki performans etkisini \u00f6l\u00e7mektir. DocumentDB 0.116’daki Herhangi bir sorgunun performans\u0131n\u0131 anlaman\u0131n en temel yolu, sorgunun nas\u0131l y\u00fcr\u00fct\u00fcld\u00fc\u011f\u00fcn\u00fc g\u00f6steren sorgu plan\u0131n\u0131 incelemektir. DocumentDB, MongoDB’nin \u00d6zellikle Ger\u00e7ek d\u00fcnya senaryolar\u0131nda, belirli bir sorguyu belirli bir veri k\u00fcmesi \u00fczerinde \u00e7al\u0131\u015ft\u0131rmak ve s\u00fcreyi \u00f6l\u00e7mek en pratik y\u00f6ntemdir. Bunu yaparken:<\/p>\n \u00d6rne\u011fin, bir raporlama sorgusunu DocumentDB 0.115’te 5 dakika s\u00fcrd\u00fc\u011f\u00fcn\u00fc, ancak DocumentDB 0.116’da ayn\u0131 veri seti ve ayn\u0131 sorgu ile 1 dakika s\u00fcrd\u00fc\u011f\u00fcn\u00fc g\u00f6zlemlemek, bu optimizasyonun ne kadar de\u011ferli oldu\u011funu g\u00f6sterir.<\/p>\n E\u011fer uygulaman\u0131zda bir APM arac\u0131 (\u00f6rne\u011fin, AWS X-Ray, Datadog, New Relic) kullan\u0131yorsan\u0131z, bu ara\u00e7lar veritaban\u0131 sorgular\u0131n\u0131n performans\u0131n\u0131 otomatik olarak izleyebilir. DocumentDB 0.116’ya ge\u00e7i\u015f yapt\u0131ktan sonra, APM arac\u0131n\u0131zdaki veritaban\u0131 performans\u0131 metriklerini (\u00f6rne\u011fin, sorgu yan\u0131t s\u00fcreleri, yava\u015f sorgular) izleyin. \u00d6zellikle APM ara\u00e7lar\u0131, sadece sorgu s\u00fcresini de\u011fil, ayn\u0131 zamanda sorgular\u0131n uygulaman\u0131n genel performans\u0131na etkisini de g\u00f6rmenizi sa\u011flar. Bu, optimizasyonun kullan\u0131c\u0131 deneyimi \u00fczerindeki ger\u00e7ek etkisini anlamak i\u00e7in \u00f6nemlidir.<\/p>\n AWS CloudWatch \u00fczerinden DocumentDB k\u00fcmenizin metriklerini de izleyebilirsiniz. \u00d6zellikle CPU kullan\u0131m\u0131, bellek kullan\u0131m\u0131 ve a\u011f trafi\u011fi gibi metrikler, sorgu performans\u0131 de\u011fi\u015fikliklerinin etkisini dolayl\u0131 olarak g\u00f6sterebilir. E\u011fer Bu izleme ve \u00f6l\u00e7\u00fcm y\u00f6ntemlerini kullanarak, DocumentDB 0.116’daki DocumentDB 0.116’daki Bu ipu\u00e7lar\u0131, DocumentDB 0.116’daki Bu optimizasyonlar \u00f6ncelikli olarak Genellikle hay\u0131r. DocumentDB 0.116’ya y\u00fckseltme yapt\u0131\u011f\u0131n\u0131zda, bu optimizasyonlar arka planda \u00e7al\u0131\u015f\u0131r ve mevcut sorgular\u0131n\u0131z\u0131n performans\u0131n\u0131 otomatik olarak iyile\u015ftirebilir. Ancak, sorgular\u0131n\u0131z\u0131 Performans kazanc\u0131n\u0131n miktar\u0131, veri setinizin b\u00fcy\u00fckl\u00fc\u011f\u00fcne, verilerdeki tekrar eden de\u011ferlerin s\u0131kl\u0131\u011f\u0131na ve sorgunuzun karma\u015f\u0131kl\u0131\u011f\u0131na ba\u011fl\u0131 olarak b\u00fcy\u00fck \u00f6l\u00e7\u00fcde de\u011fi\u015fiklik g\u00f6sterebilir. Baz\u0131 senaryolarda %10-20’lik bir iyile\u015fme g\u00f6r\u00fcl\u00fcrken, tekrarlayan de\u011ferlerin \u00e7ok yo\u011fun oldu\u011fu b\u00fcy\u00fck veri setlerinde bu oran %50 veya daha fazla olabilir.<\/p>\n Bu spesifik Hay\u0131r, bu optimizasyonlar do\u011frudan AWS DocumentDB 0.116 s\u00fcr\u00fcm\u00fc ile gelen #DocumentDB #AWS #NoSQL #Veritaban\u0131 #PerformansOptimizasyonu #Aggregation #MongoDBAPI<\/p>\n$group<\/code> a\u015famas\u0131ndaki benzersiz tarama (distinct scan) \u00f6zelli\u011fi, bu t\u00fcr senaryolarda \u00f6nemli bir optimizasyon sunuyor. Peki, bu yeni \u00f6zellik tam olarak ne i\u015fe yar\u0131yor ve geli\u015ftiriciler i\u00e7in ne gibi avantajlar sa\u011fl\u0131yor? Gelin, bu konuyu derinlemesine inceleyelim.<\/p>\nNeden Benzersiz Veri Taramas\u0131 \u00d6nemli?<\/h2>\n
$group<\/code> a\u015famas\u0131nda benzersiz veri taramas\u0131 devreye giriyor.<\/p>\n$group<\/code> a\u015famas\u0131ndaki $addToSet<\/code> veya $first<\/code>, $last<\/code> gibi operat\u00f6rlerle birlikte kullan\u0131lan benzersiz tarama optimizasyonlar\u0131, bu s\u00fcreci daha verimli hale getiriyor. Bu, veritaban\u0131n\u0131n, ayn\u0131 alan i\u00e7in birden fazla tekrar eden de\u011feri i\u015flerken gereksiz hesaplamalardan ka\u00e7\u0131nmas\u0131n\u0131 sa\u011fl\u0131yor. Temelde, veritaban\u0131 motoru, belirli bir anahtara (field) sahip benzersiz de\u011ferleri daha ak\u0131ll\u0131ca takip edebiliyor ve bu sayede hem i\u015flem g\u00fcc\u00fcnden tasarruf ediyor hem de sorgu s\u00fcresini \u00f6nemli \u00f6l\u00e7\u00fcde k\u0131salt\u0131yor.<\/p>\nDocumentDB 0.116’da $group ve Benzersiz Taramaya Giri\u015f<\/h2>\n
$group<\/code> a\u015famas\u0131, bu \u00e7er\u00e7evenin en temel ve en s\u0131k kullan\u0131lan a\u015famalar\u0131ndan biridir. Belirli bir anahtara (field) g\u00f6re belgeleri grupland\u0131rmam\u0131z\u0131 ve bu gruplar \u00fczerinde toplama i\u015flemleri yapmam\u0131z\u0131 sa\u011flar. \u00d6rne\u011fin, t\u00fcm sipari\u015fleri m\u00fc\u015fteri kimli\u011fine g\u00f6re grupland\u0131r\u0131p her m\u00fc\u015fterinin toplam harcamas\u0131n\u0131 hesaplayabiliriz.<\/p>\n$group<\/code> a\u015famas\u0131nda belirli bir alana g\u00f6re benzersiz de\u011ferleri toplamak istedi\u011fimizde, veritaban\u0131 motoru bu de\u011feri her g\u00f6rd\u00fc\u011f\u00fcnde bir i\u015flem yapmaya meyilliydi. E\u011fer ayn\u0131 de\u011fere sahip y\u00fczlerce, binlerce belge varsa, bu de\u011fer defalarca i\u015flenirdi. Bu durum, \u00f6zellikle b\u00fcy\u00fck veri k\u00fcmelerinde ve yo\u011fun tekrarlayan de\u011ferlerde ciddi bir performans y\u00fck\u00fc olu\u015ftururdu. D\u00fc\u015f\u00fcn\u00fcn ki, milyonlarca i\u015flem kayd\u0131 var ve siz bu kay\u0131tlardaki benzersiz \u00fcr\u00fcn ID’lerini listelemek istiyorsunuz. E\u011fer her bir i\u015flem kayd\u0131 i\u00e7in \u00fcr\u00fcn ID’si i\u015fleniyorsa, bu \u00e7ok zaman al\u0131c\u0131 ve kaynak t\u00fcketen bir i\u015flem olurdu.<\/p>\n$group<\/code> a\u015famas\u0131ndaki baz\u0131 toplama operat\u00f6rleri, benzersiz de\u011ferleri daha verimli bir \u015fekilde i\u015flemek \u00fczere optimize edildi. Bu optimizasyon, veritaban\u0131 motorunun, belirli bir grupland\u0131rma anahtar\u0131 i\u00e7in zaten kar\u015f\u0131la\u015ft\u0131\u011f\u0131 bir de\u011feri tekrar tekrar i\u015flemek yerine, o de\u011feri yaln\u0131zca bir kez i\u015flemesini veya benzersizli\u011fini daha h\u0131zl\u0131 bir \u015fekilde kontrol etmesini sa\u011flar. Bu, \u00f6zellikle $addToSet<\/code> gibi operat\u00f6rler kullan\u0131ld\u0131\u011f\u0131nda belirginle\u015fir. $addToSet<\/code>, bir diziye yaln\u0131zca o \u00f6\u011fe zaten mevcut de\u011filse ekleme yapar. Eski s\u00fcr\u00fcmlerde, bir \u00f6\u011fenin zaten mevcut olup olmad\u0131\u011f\u0131n\u0131 kontrol etmek i\u00e7in daha fazla \u00e7aba gerekebilirken, yeni optimizasyonlar bu kontrol\u00fc daha h\u0131zl\u0131 hale getirir.<\/p>\nGer\u00e7ek D\u00fcnya Senaryosu: E-Ticaret Platformunda Benzersiz Ziyaret\u00e7i Takibi<\/h2>\n
\n [\n {\n $group: {\n _id: \"$userID\", \/\/ Kullan\u0131c\u0131 kimli\u011fine g\u00f6re grupla\n \/\/ Bu a\u015famada sadece benzersiz userID'leri topluyoruz,\n \/\/ her bir userID'nin bir kez g\u00f6r\u00fcnmesi yeterli.\n }\n },\n {\n $count: \"distinctUsers\" \/\/ Gruplanan belgelerin say\u0131s\u0131n\u0131 al\n }\n ]\n <\/code><\/pre>\n$group<\/code> a\u015famas\u0131, t\u00fcm belgeleri userID<\/code> alan\u0131na g\u00f6re gruplar. E\u011fer bir kullan\u0131c\u0131n\u0131n y\u00fczlerce g\u00f6r\u00fcnt\u00fcleme kayd\u0131 varsa, bu userID<\/code> defalarca i\u015flenir. \u0130kinci $count<\/code> a\u015famas\u0131 ise bu gruplar\u0131n say\u0131s\u0131n\u0131 verir. Ancak, ilk $group<\/code> a\u015famas\u0131n\u0131n kendisi, e\u011fer optimize edilmemi\u015fse, b\u00fcy\u00fck veri setlerinde yava\u015f \u00e7al\u0131\u015fabilir \u00e7\u00fcnk\u00fc her bir belge i\u00e7in userID<\/code> alan\u0131n\u0131 kontrol etmesi ve gruplama yapmas\u0131 gerekir.<\/p>\n$group<\/code> a\u015famas\u0131ndaki dahili optimizasyonlar sayesinde daha verimli hale gelir. Veritaban\u0131 motoru, belirli bir userID<\/code> ile kar\u015f\u0131la\u015ft\u0131\u011f\u0131nda, bu userID<\/code>‘nin zaten gruplar aras\u0131nda olup olmad\u0131\u011f\u0131n\u0131 daha h\u0131zl\u0131 bir \u015fekilde tespit edebilir. Bu, \u00f6zellikle $addToSet<\/code> gibi operat\u00f6rlerle birlikte kullan\u0131ld\u0131\u011f\u0131nda daha da belirginle\u015fir. \u00d6rne\u011fin, her kullan\u0131c\u0131n\u0131n g\u00f6r\u00fcnt\u00fcledi\u011fi benzersiz<\/strong> \u00fcr\u00fcnleri listelemek istedi\u011fimizde:<\/p>\n\n [\n {\n $group: {\n _id: \"$userID\",\n viewedProducts: { $addToSet: \"$productID\" } \/\/ Her kullan\u0131c\u0131 i\u00e7in benzersiz \u00fcr\u00fcn ID'lerini bir set'e ekle\n }\n },\n {\n $project: {\n _id: 0,\n userID: \"$_id\",\n numberOfUniqueProducts: { $size: \"$viewedProducts\" } \/\/ G\u00f6r\u00fcnt\u00fclenen benzersiz \u00fcr\u00fcn say\u0131s\u0131\n }\n }\n ]\n <\/code><\/pre>\n$addToSet: \"$productID\"<\/code> operat\u00f6r\u00fc, her bir userID<\/code> grubuna ait productID<\/code>‘leri bir diziye eklerken, yaln\u0131zca daha \u00f6nce eklenmemi\u015f olanlar\u0131 ekler. DocumentDB 0.116’daki optimizasyonlar, bu $addToSet<\/code> i\u015fleminin daha h\u0131zl\u0131 ger\u00e7ekle\u015fmesini sa\u011flar. Veritaban\u0131, bir productID<\/code>‘nin zaten o kullan\u0131c\u0131n\u0131n viewedProducts<\/code> setinde olup olmad\u0131\u011f\u0131n\u0131 daha etkin bir \u015fekilde kontrol eder. Bu, \u00f6zellikle bir kullan\u0131c\u0131n\u0131n \u00e7ok say\u0131da farkl\u0131 \u00fcr\u00fcn\u00fc g\u00f6r\u00fcnt\u00fcledi\u011fi durumlarda veya ayn\u0131 \u00fcr\u00fcnleri tekrar tekrar g\u00f6r\u00fcnt\u00fcledi\u011fi durumlarda performans\u0131 art\u0131r\u0131r.<\/p>\n$group A\u015famas\u0131ndaki Optimizasyonlar Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h2>\n
$group<\/code> a\u015famas\u0131ndaki benzersiz tarama optimizasyonlar\u0131n\u0131n tam olarak nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 anlamak i\u00e7in, veritaban\u0131 motorlar\u0131n\u0131n toplama i\u015flemleri s\u0131ras\u0131nda kulland\u0131\u011f\u0131 genel stratejilere g\u00f6z atmak faydal\u0131 olacakt\u0131r. Genellikle, bir $group<\/code> a\u015famas\u0131, verileri bellekte veya diskte ge\u00e7ici olarak depolayarak \u00e7al\u0131\u015f\u0131r. Veriler, belirtilen anahtarlara g\u00f6re gruplan\u0131r ve her grup i\u00e7in toplama i\u015flemleri (\u00f6rne\u011fin, sayma, toplama, ortalama alma) ger\u00e7ekle\u015ftirilir.<\/p>\n$group<\/code> a\u015famas\u0131 belirli bir alana g\u00f6re benzersiz de\u011ferleri toplamak istedi\u011finde (\u00f6rne\u011fin, $addToSet<\/code> kullanarak), veritaban\u0131 motoru her bir belgeyi i\u015flerken \u015fu ad\u0131mlar\u0131 izleyebilirdi:<\/p>\n\n
userID<\/code>).<\/li>\nproductID<\/code>) ait de\u011feri al.<\/li>\n$addToSet<\/code> durumunda, bu de\u011ferin zaten grubun dizi i\u00e7inde olup olmad\u0131\u011f\u0131n\u0131 kontrol et ve de\u011filse ekle.<\/li>\n<\/ol>\n\n
$group<\/code> a\u015famas\u0131ndaki bu t\u00fcr operat\u00f6rler i\u00e7in veritaban\u0131 motorunun “ak\u0131ll\u0131” hale gelmesini sa\u011flam\u0131\u015ft\u0131r. Motor, art\u0131k sadece gelen veriyi i\u015flemekle kalm\u0131yor, ayn\u0131 zamanda i\u015fledi\u011fi verinin benzersizli\u011fini daha proaktif ve verimli bir \u015fekilde y\u00f6netiyor. Bu, geli\u015ftiricilerin sorgular\u0131n\u0131 de\u011fi\u015ftirmeden daha iyi performans elde etmelerini sa\u011flar.<\/p>\nPerformans Kazanc\u0131n\u0131 \u00d6l\u00e7mek ve \u0130zlemek<\/h2>\n
$group<\/code> optimizasyonlar\u0131 i\u00e7in de durum ayn\u0131d\u0131r. Performans kazanc\u0131n\u0131 anlamak ve izlemek i\u00e7in birka\u00e7 y\u00f6ntem mevcuttur:<\/p>\n1. Sorgu Plan\u0131 Analizi (Query Plan Analysis)<\/h3>\n
explain()<\/code> komutunu destekler. Bu komut, sorgunun hangi a\u015famalardan ge\u00e7ti\u011fini, hangi indekslerin kullan\u0131ld\u0131\u011f\u0131n\u0131 ve her a\u015faman\u0131n ne kadar zaman ve kaynak t\u00fcketti\u011fini detayl\u0131 olarak g\u00f6sterir.<\/p>\n$group<\/code> a\u015famas\u0131n\u0131n maliyetini kar\u015f\u0131la\u015ft\u0131rmak i\u00e7in, ayn\u0131 sorguyu hem DocumentDB 0.116 \u00f6ncesi bir s\u00fcr\u00fcmde (varsa) hem de 0.116 s\u00fcr\u00fcm\u00fcnde explain()<\/code> ile \u00e7al\u0131\u015ft\u0131r\u0131n. executionStats<\/code> se\u00e7ene\u011fi, sorgunun ger\u00e7ek \u00e7al\u0131\u015fma istatistiklerini, yani ge\u00e7en s\u00fcreyi, i\u015flenen belge say\u0131s\u0131n\u0131 ve bellek kullan\u0131m\u0131n\u0131 g\u00f6sterir. Bu kar\u015f\u0131la\u015ft\u0131rma, $group<\/code> a\u015famas\u0131ndaki i\u015flem s\u00fcresinde veya bellek kullan\u0131m\u0131nda ne kadar bir azalma oldu\u011funu net bir \u015fekilde ortaya koyacakt\u0131r.<\/p>\nexplain()<\/code> \u00e7\u0131kt\u0131s\u0131nda dikkat edilmesi gereken anahtar metrikler \u015funlard\u0131r:<\/p>\n\n
executionTimeMillis<\/code>: Sorgunun tamam\u0131n\u0131n veya belirli bir a\u015famas\u0131n\u0131n milisaniye cinsinden \u00e7al\u0131\u015fma s\u00fcresi.<\/li>\ntotalDocsExamined<\/code>: Sorgu taraf\u0131ndan taranan toplam belge say\u0131s\u0131.<\/li>\ntotalKeysExamined<\/code>: Sorgu taraf\u0131ndan taranan toplam indeks anahtar\u0131 say\u0131s\u0131.<\/li>\nmemUsageBytes<\/code>: Sorgunun kulland\u0131\u011f\u0131 bellek miktar\u0131 (varsa).<\/li>\nstage<\/code>: Sorgu plan\u0131ndaki a\u015faman\u0131n ad\u0131 (\u00f6rne\u011fin, GROUP<\/code>).<\/li>\n<\/ul>\n2. Zaman Bazl\u0131 Kar\u015f\u0131la\u015ft\u0131rma<\/h3>\n
\n
3. Application Performance Monitoring (APM) Ara\u00e7lar\u0131<\/h3>\n
$group<\/code> i\u00e7eren toplama sorgular\u0131n\u0131n yan\u0131t s\u00fcrelerindeki belirgin d\u00fc\u015f\u00fc\u015fleri g\u00f6zlemleyebilirsiniz.<\/p>\n4. DocumentDB Metrikleri<\/h3>\n
$group<\/code> optimizasyonlar\u0131 ba\u015far\u0131l\u0131 olursa, benzer i\u015f y\u00fckleri i\u00e7in CPU ve bellek kullan\u0131m\u0131nda d\u00fc\u015f\u00fc\u015fler g\u00f6rmeniz muhtemeldir.<\/p>\n$group<\/code> optimizasyonlar\u0131n\u0131n uygulaman\u0131z i\u00e7in sa\u011flad\u0131\u011f\u0131 somut faydalar\u0131 belgeleyebilir ve bu ge\u00e7i\u015fin do\u011fru bir karar oldu\u011funu teyit edebilirsiniz.<\/p>\n\u0130leri D\u00fczey \u0130pu\u00e7lar\u0131 ve P\u00fcf Noktalar\u0131<\/h2>\n
$group<\/code> optimizasyonlar\u0131ndan en iyi \u015fekilde yararlanmak i\u00e7in, geli\u015ftiricilerin dikkate almas\u0131 gereken baz\u0131 ileri d\u00fczey ipu\u00e7lar\u0131 ve p\u00fcf noktalar\u0131 bulunmaktad\u0131r:<\/p>\n\n
$addToSet<\/code>, $first<\/code>, $last<\/code> gibi belirli toplama operat\u00f6rleri i\u00e7in ge\u00e7erlidir. E\u011fer amac\u0131n\u0131z sadece benzersiz bir de\u011ferin say\u0131s\u0131n\u0131 elde etmekse, bazen $group<\/code> yerine $group<\/code> ve ard\u0131ndan $count<\/code> kullanmak daha net olabilir. Ancak, e\u011fer benzersiz de\u011ferlerin kendisini veya bunlarla ili\u015fkili di\u011fer bilgileri (\u00f6rne\u011fin, ilk g\u00f6r\u00fclen de\u011feri) elde etmek istiyorsan\u0131z, $addToSet<\/code> veya $first<\/code> gibi operat\u00f6rler ve optimizasyonlar devreye girer.<\/li>\n$group<\/code> optimizasyonlar\u0131 indekslerden ba\u011f\u0131ms\u0131z olarak \u00e7al\u0131\u015fabilse de, do\u011fru indeksler sorgu performans\u0131n\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde art\u0131rabilir. E\u011fer $group<\/code> a\u015famas\u0131ndan \u00f6nce $match<\/code> a\u015famas\u0131 varsa ve bu a\u015fama belirli alanlara g\u00f6re filtreleme yap\u0131yorsa, bu alanlar \u00fczerinde indeks olu\u015fturmak, $group<\/code> a\u015famas\u0131na ula\u015facak belge say\u0131s\u0131n\u0131 azaltarak genel performans\u0131 iyile\u015ftirir. Ayr\u0131ca, grupland\u0131rma anahtar\u0131 (_id<\/code> alan\u0131) \u00fczerinde bir indeksin olmas\u0131 da baz\u0131 durumlarda faydal\u0131 olabilir.<\/li>\n$group<\/code> i\u015flemleri hala \u00f6nemli miktarda bellek t\u00fcketebilir. DocumentDB, belle\u011fi verimli kullanmak i\u00e7in optimize edilmi\u015ftir, ancak sorgular\u0131n\u0131z\u0131n bellek s\u0131n\u0131rlar\u0131n\u0131 zorlamad\u0131\u011f\u0131ndan emin olun. Sorgu plan\u0131n\u0131 analiz ederken bellek kullan\u0131m\u0131n\u0131 (varsa) kontrol edin. Gerekirse, sorguyu daha k\u00fc\u00e7\u00fck par\u00e7alara b\u00f6lmek veya ara sonu\u00e7lar\u0131 diskte daha verimli i\u015flemek i\u00e7in daha geli\u015fmi\u015f stratejiler d\u00fc\u015f\u00fcnebilirsiniz.<\/li>\n$facet<\/code> Kullan\u0131m\u0131:<\/strong> E\u011fer birden fazla farkl\u0131 toplama ve gruplama i\u015flemini tek bir sorguda yapmak istiyorsan\u0131z, $facet<\/code> a\u015famas\u0131n\u0131 kullanabilirsiniz. $facet<\/code>, her bir alt-pipeline’\u0131n kendi sonu\u00e7lar\u0131n\u0131 \u00fcretmesini sa\u011flar ve bu sonu\u00e7lar daha sonra birle\u015ftirilir. 0.116 s\u00fcr\u00fcm\u00fcndeki $group<\/code> optimizasyonlar\u0131, $facet<\/code> i\u00e7indeki pipeline’larda da ge\u00e7erli olacakt\u0131r, bu da karma\u015f\u0131k analizlerin daha verimli y\u00fcr\u00fct\u00fclmesini sa\u011flar.<\/li>\n$group<\/code> optimizasyonlar\u0131ndan en \u00fcst d\u00fczeyde faydalanman\u0131za yard\u0131mc\u0131 olacakt\u0131r. Unutmay\u0131n ki, en iyi performans genellikle do\u011fru veri modellemesi, etkili indeksleme ve veritaban\u0131 \u00f6zelliklerinin do\u011fru anla\u015f\u0131lmas\u0131yla elde edilir.<\/p>\nS\u0131k\u00e7a Sorulan Sorular (SSS)<\/h2>\n
1. DocumentDB 0.116’daki $group optimizasyonu hangi operat\u00f6rleri etkiler?<\/h3>\n
$group<\/code> a\u015famas\u0131nda kullan\u0131lan ve benzersiz de\u011ferleri toplama veya i\u015fleme ihtiyac\u0131 duyan operat\u00f6rleri hedefler. Bunlara $addToSet<\/code>, $first<\/code>, $last<\/code> gibi operat\u00f6rler dahildir. Temel olarak, bir grup i\u00e7indeki belirli bir alana ait benzersiz de\u011ferleri daha verimli bir \u015fekilde y\u00f6netmeye odaklan\u0131r.<\/p>\n2. Bu optimizasyonlar i\u00e7in sorgular\u0131m\u0131 de\u011fi\u015ftirmem gerekir mi?<\/h3>\n
explain()<\/code> ile analiz ederek performans art\u0131\u015f\u0131n\u0131 do\u011frulaman\u0131z \u00f6nerilir.<\/p>\n3. Performans kazanc\u0131 ne kadar olur?<\/h3>\n
4. Bu \u00f6zellik hangi DocumentDB s\u00fcr\u00fcmlerinde mevcuttur?<\/h3>\n
$group<\/code> optimizasyonlar\u0131 DocumentDB’nin 0.116 s\u00fcr\u00fcm\u00fc ile tan\u0131t\u0131lm\u0131\u015ft\u0131r. Daha \u00f6nceki s\u00fcr\u00fcmlerde bu d\u00fczeyde bir optimizasyon bulunmamaktad\u0131r.<\/p>\n5. Bu optimizasyonlar $match veya $sort gibi a\u015famalar\u0131 da etkiler mi?<\/h3>\n
$group<\/code> a\u015famas\u0131na odaklanm\u0131\u015ft\u0131r. $match<\/code> (filtreleme) ve $sort<\/code> (s\u0131ralama) gibi di\u011fer a\u015famalardaki performans iyile\u015ftirmeleri i\u00e7in farkl\u0131 indeksleme stratejileri veya DocumentDB’nin genel s\u00fcr\u00fcm g\u00fcncellemeleri dikkate al\u0131nmal\u0131d\u0131r.<\/p>\nSonu\u00e7<\/h2>\n
$group<\/code> a\u015famas\u0131ndaki benzersiz tarama (distinct scan) optimizasyonlar\u0131, NoSQL veritaban\u0131 toplama i\u015flemlerinde \u00f6nemli bir ilerlemeyi temsil ediyor. Bu geli\u015ftirmeler, \u00f6zellikle b\u00fcy\u00fck veri setlerinde tekrarlayan de\u011ferleri i\u015flerken kar\u015f\u0131la\u015f\u0131lan performans darbo\u011fazlar\u0131n\u0131 hafifletmek i\u00e7in tasarlanm\u0131\u015ft\u0131r. Geli\u015ftiriciler, sorgular\u0131n\u0131 de\u011fi\u015ftirmeden daha h\u0131zl\u0131 ve daha verimli analizler yapabilirler. E-ticaret platformlar\u0131ndaki kullan\u0131c\u0131 takibi, finansal i\u015flemlerdeki benzersiz hareketlerin analizi veya IoT cihazlar\u0131ndan gelen verilerdeki tekrarlayan olaylar\u0131n tespiti gibi bir\u00e7ok ger\u00e7ek d\u00fcnya senaryosunda bu optimizasyonlar somut faydalar sa\u011flayacakt\u0131r. Sorgu planlar\u0131n\u0131 analiz ederek, zaman bazl\u0131 testler yaparak ve APM ara\u00e7lar\u0131n\u0131 kullanarak bu performans kazanc\u0131n\u0131 \u00f6l\u00e7mek ve do\u011frulamak m\u00fcmk\u00fcnd\u00fcr. DocumentDB’nin s\u00fcrekli geli\u015fen yap\u0131s\u0131, bulut tabanl\u0131 veritaban\u0131 \u00e7\u00f6z\u00fcmlerinde performans\u0131 ve verimlili\u011fi art\u0131rmaya devam edece\u011finin bir g\u00f6stergesidir.<\/p>\n