filtreleme uygulaması için elasticsearch vs MongoDB [kapalı]

Bu soru, deneme ve uygulamanın ayrıntılarına girmeden önce mimari bir seçim yapmakla ilgilidir. Bu, belirli bir amaç için elasticsearch vs MongoDB'nin ölçeklenebilirliği ve performans açısından uygunluğu ile ilgilidir.

Varsayımsal olarak, hem alanlara hem de değerlere sahip veri nesnelerini depolar ve bu nesne gövdesinin sorgulanmasına izin verir. Bu nedenle, nesnelerin alt kümelerini geçici olarak seçilen alanlara göre filtrelemek, her ikisi için de uygun bir şeydir.

Uygulamam, ölçütlere göre nesne seçme etrafında dönecektir. Nesneleri aynı anda tek bir alandan daha fazla filtreleyerek seçer, farklı bir şekilde ifade eder, sorgu filtreleme kriterleri tipik olarak 1 ila 5 alan arasında, belki de bazı durumlarda daha fazla yer alır. Oysa filtre olarak seçilen alanlar çok daha büyük bir alanın alt kümesi olacaktır. Mevcut bazı 20 alan adlarını resmedin ve her sorgu, nesneleri toplam 20 alanın birkaç alanına göre filtreleme girişimidir (20 alan adından daha az veya daha fazla olabilir, bu sayıyı oranını göstermek için kullandım. alanlardan her ayrık sorguda filtre olarak kullanılan alanlara). Filtreleme, seçilen alanların varlığının yanı sıra alan değerleriyle de olabilir, örneğin A alanına sahip nesneleri filtrelemek ve B alanları x ile y arasında,

Uygulamam bu tür filtrelemeyi sürekli yapacaktır, oysa filtreleme için hangi alanların her an kullanıldığı konusunda hiçbir şey veya çok az sabit olmayacaktır. Belki de elasticsearch dizinleri tanımlanmalıdır, ancak belki dizin olmadan bile hız MongoDB ile eşittir.

Mağazaya giren verilere göre, bununla ilgili özel bir detay yok .. nesneler yerleştirildikten sonra neredeyse hiç değişmeyecekti. Belki de eski nesnelerin bırakılması gerekir, her iki veri deposu desteğinin süresinin dolmasını dahili olarak veya uygulama tarafından yapılan bir sorgu ile varsayalım. (Daha az sıklıkla, belirli bir sorguya uyan nesnelerin de bırakılması gerekir).

Ne düşünüyorsun? Ve bu yönü denediniz mi?

Bu tür bir görev için, iki veri deposunun her birinin performansı ve ölçeklenebilirliği ile ilgileniyorum. Bu bir tür mimari tasarım sorusudur ve mağazaya özgü seçeneklerin veya iyi tasarlanmış olması gereken sorgu köşe taşlarının ayrıntıları, tamamen düşünülmüş bir önerinin bir gösterimi olarak kabul edilir.

Teşekkürler!

Öncelikle, burada önemli bir ayrım var: MongoDB genel amaçlı bir veritabanı, Elasticsearch, Lucene tarafından desteklenen dağıtılmış bir metin arama motorudur. İnsanlar Elasticsearch'ü genel amaçlı bir veritabanı olarak kullanmaktan bahsediyorlar, ancak bunun orijinal tasarımı olmadığını biliyorlar. Genel amaçlı NoSQL veritabanlarının ve arama motorlarının konsolidasyona yöneldiğini düşünüyorum, ancak olduğu gibi, ikisi çok farklı iki kamptan geliyor.

Şirketimde hem MongoDB hem de Elasticsearch kullanıyoruz. Verilerimizi MongoDB'de saklıyoruz ve Elasticsearch'ü yalnızca tam metin arama özellikleri için kullanıyoruz. Biz sadece elastiğe sorgulamamız gereken mongo veri alanlarının bir alt kümesini gönderiyoruz. Kullanım durumumuz, Mongo verilerimizin her zaman değişmesi nedeniyle sizinkinden farklıdır: bir kayıt veya bir kayıt alanlarının bir alt kümesi, günde birkaç kez güncellenebilir ve bu, o kaydın elastikliğe yeniden endekslenmesini gerektirebilir. Bu nedenle, tek başına veri deposu olarak elastiki kullanmak bizim için iyi bir seçenek değildir, çünkü belirli alanları güncelleyemeyiz; bir belgeyi bütünüyle yeniden dizine eklememiz gerekir. Bu elastik bir sınırlama değildir, elastikin altında yatan arama motoru olan Lucene bu şekilde çalışır. Sizin durumunuzda, kayıtların kazanması ' t saklandıktan sonra bu seçimi yapmak zorunda kalmazsınız değiştirilir. Veri güvenliği bir endişe ise, Elasticsearch'ü verileriniz için tek depolama mekanizması olarak kullanmayı iki kez düşünürdüm. Bir noktada oraya gelebilir ama henüz orada olduğundan emin değilim.

Hız açısından, Elastik / Lucene sadece Mongo'nun sorgulama hızıyla eşit değil, "herhangi bir anda filtreleme için hangi alanların kullanıldığı konusunda çok az sabit" olması durumunda, özellikle veri kümeleri büyüdükçe daha hızlı olur. Fark, temeldeki sorgu uygulamalarında yatmaktadır:

• Elastik / Lucene , bir sorgu ile kayıt benzerliğini karşılaştırmanın oldukça etkili yolları olan Bilgi Alma için Vector Space Modelini ve tersine çevrilmiş dizinleri kullanır. Elastik / Lucene'yi sorguladığınızda, cevabı zaten biliyor; çalışmalarının çoğu, sizin için sonuçları, sorgu terimlerinizle eşleşmesi en olası olanlara göre sıralamaktır. Bu önemli bir nokta: arama motorları, veritabanlarının aksine, kesin sonuçları garanti edemez; sonuçları sorgunuza ne kadar yaklaştıklarına göre sıralarlar. Çoğu zaman, sonuçlar tam olarak yakındır.
• Mongo'nun yaklaşımı daha genel amaçlı bir veri deposudur; JSON belgelerini birbirleriyle karşılaştırır. Elbette harika bir performans elde edebilirsiniz, ancak çalıştıracağınız sorgularla eşleştirmek için dizinlerinizi dikkatlice oluşturmalısınız. Özellikle, sorgulayacağınız birden fazla alanınız varsa, bileşik anahtarlarınızı dikkatli bir şekilde oluşturmanız gerekirböylece sorgulanacak veri kümesini olabildiğince hızlı bir şekilde azaltırlar. Örneğin, ilk anahtarınız veri kümenizin çoğunu filtrelemeli, ikinciniz kalanları daha fazla filtrelemelidir, vb. Sorgularınız anahtarlarla ve tanımlı dizinlerdeki bu anahtarların sırasıyla eşleşmezse, performansınız biraz düşecektir. Öte yandan, Mongo gerçek bir veritabanıdır, bu yüzden doğruluk ihtiyacınız olan şeyse, vereceği cevaplar yerinde olacaktır.

Eski kayıtların süresinin dolması için Elastik'in yerleşik bir TTL özelliği vardır. Mongo sadece 2.2 sürümünden itibaren tanıttı.

Beklenen veri boyutu, işlemler, doğruluk veya filtrelerinizin nasıl görüneceği gibi diğer gereksinimlerinizi bilmediğim için, belirli önerilerde bulunmak zor. İnşallah, burada başlamanıza yetecek kadar var.