Esnek arama, birden çok dizin vs bir dizin ve farklı veri kümeleri için türler?


161

Ben MVC desen kullanılarak geliştirilen bir uygulama var ve şimdi birden çok modelini indekslemek istiyorum, bu her model farklı bir veri yapısına sahip olduğu anlamına gelir.

  • Her model için bir tane olmak veya her model için aynı dizin içinde bir türe sahip olmak için birden çok dizin kullanmak daha mı iyi? Her iki yol da bence farklı bir arama sorgusu gerektirir. Ben daha yeni başladım.

  • Veri kümesi küçük veya çok büyükse, her iki kavram arasında da performans farklılıkları var mı?

Birisi bana bu amaç için bazı iyi örnek veriler önerebilirse 2. soruyu kendim test ederim.

Yanıtlar:


184

Her iki yaklaşımın da farklı çıkarımları vardır.

Elasticsearch'ün varsayılan ayarlarını kullandığınızı varsayarsak, her bir model için 1 indeks olması, 1 indeks 5 kırık, 5 veri modeli 25 kırık kullanacağından, parçalarınızın sayısını önemli ölçüde artıracaktır; 1 indekste 5 nesne tipine sahip olmakla birlikte 5 parça kullanılacaktır.

Her veri modelini dizin olarak almanın sonuçları:

  • Farklı endekslere dağıtıldığından, her parçada veri miktarı daha az olması gerektiğinden, indeks içinde verimli ve hızlı arama.
  • 2 veya daha fazla endeksten veri modellerinin bir kombinasyonunu aramak yükü oluşturacaktır, çünkü sorgu indeksler arasında daha fazla parçaya gönderilecek, derlenecek ve kullanıcıya geri gönderilecektir.
  • Oluşturulan her ek parça ile daha fazla depolama alanına gireceğiniz ve performans kazancı marjinal olduğu için veri kümeniz küçükse önerilmez.
  • Veri kümeniz büyükse ve sorgularınızın işlenmesi uzun sürüyorsa önerilir, çünkü özel parçalar özel verilerinizi depolar ve Elasticsearch'ün işlenmesi daha kolay olur.

Her veri modelinin bir dizin içinde nesne türü olarak bulunmasının sonuçları:

  • Bir dizinin 5 parçası içinde daha fazla veri depolanır, bu da farklı veri modellerinde sorgulama yaparken daha az genel sorun olduğu anlamına gelir, ancak parça boyutunuz önemli ölçüde daha büyük olacaktır.
  • Kırıntılar içindeki daha fazla veri, filtrelenecek daha fazla belge olduğundan Elasticsearch'ün arama yapması daha uzun zaman alacaktır.
  • 1 terabayt veri geçtiğinizi ve verilerinizi Elasticsearch eşlemenizdeki farklı indekslere veya birden çok parçaya dağıtmadığınızı biliyorsanız önerilmez.
  • Küçük veri kümeleri için önerilir, çünkü her parça donanımınızda yer kapladığından marjinal performans artışı için depolama alanını boşa harcamazsınız.

Küçük verilere göre çok fazla verinin ne olduğunu soruyorsanız? Genellikle, işlemci hızına ve donanımınızın RAM'ine, Elasticsearch eşlemenizde her bir değişken içinde sakladığınız veri miktarına ve sorgu gereksinimlerinize bağlıdır; sorgularınızda birçok yön kullanmak yanıt sürenizi önemli ölçüde yavaşlatacaktır. Bunun basit bir cevabı yoktur ve ihtiyaçlarınıza göre kıyaslama yapmanız gerekecektir.


8
Bu cevap dan bilgi olmadan tamamlanmış değil elasticsearch.org/guide/en/elasticsearch/guide/current/...
AndreKR

5
Mükemmel cevaba eklemek için, neden çok sayıda kırığı korumanın önerilmediğini açıklayan ES 5.2 belgesinden alıntı yapıyorum : " By default elasticsearch rejects search requests that would query more than 1000 shards. The reason is that such large numbers of shards make the job of the coordinating node very CPU and memory intensive. It is usually a better idea to organize data in such a way that there are fewer larger shards. In case you would like to bypass this limit, which is discouraged, you can update the action.search.shard_count.limit cluster setting to a greater value."
unutulma

49

Jonathan'ın cevabı o zaman doğru olmasına rağmen, dünya ilerledi ve şimdi Elastik Arama'nın arkasındaki insanların birden fazla türe destek vermek için uzun vadeli bir planı var gibi görünüyor:

Nereye ulaşmak istiyoruz: Ebeveyn / çocuğu desteklerken, tip kavramını Elasticsearch'ten kaldırmak istiyoruz.

Bu nedenle, yeni projeler için, dizin başına yalnızca tek bir tür kullanılması, sonuçta RubberSearch 6.x'e yükseltmenin daha kolay olmasını sağlayacaktır.


13

Jonathan'ın cevabı harika. Dikkate alınması gereken birkaç nokta daha ekleyeceğim:

  • Kırık sayısı seçtiğiniz çözüme göre özelleştirilebilir. 15 birincil parça içeren bir dizininiz olabilir veya 5 parça için 3 dizine bölebilirsiniz - performans perspektifi değişmez (verilerin eşit olarak dağıtıldığı varsayılarak)
  • veri kullanımını düşünün. Yani. görselleştirmek için kibana kullanıyorsanız, belirli dizinleri eklemek / hariç tutmak daha kolaydır, ancak türlerin kontrol panelinde filtrelenmesi gerekir
  • veri saklama: uygulama günlüğü / metrik verileri için farklı saklama süresine ihtiyacınız varsa farklı dizinler kullanın

Saklama süresi ne anlama geliyor? Yaşam alanından bahsediyor musunuz? Bu belge başına ayarlanır.
Kshitiz Sharma

Hayır, burada saklama süresi belge / dizin saklama - bu verilerin ne kadar süre saklanacağı anlamına gelir. Veri kalitesine, büyüklüğüne, önemine bağlı olarak - Farklı saklama politikaları belirlemek için kullanıyorum. Bazı veriler / dizinler 7 gün sonra, bazıları 6w sonra ve bazıları 10 yıl sonra silinir ...
Marcel Matus

2

Yukarıdaki cevapların ikisi de harika!

Bir dizinde birkaç tür örneği ekliyorum. Bir kitaplıkta kitap aramak için bir uygulama geliştirdiğinizi varsayalım. Kütüphane sahibine sorulacak birkaç soru var,

Sorular:

  1. Kaç kitap saklamayı planlıyorsunuz?

  2. Kütüphanede ne tür kitaplar saklayacaksınız?

  3. Kitapları nasıl arayacaksınız?

Yanıtlar:

  1. 50 k - ila 70 k kitap saklamayı planlıyorum (yaklaşık)

  2. 15 k -20 k teknoloji ile ilgili kitaplara (bilgisayar bilimi, makine mühendisliği, kimya mühendisliği vb.), 15 k tarihi kitaplara, 10 k tıp bilimi kitaplarına sahip olacağım. 10 k dil ile ilgili kitap (İngilizce, İspanyolca vb.)

  3. Yazarların adına göre, yazarın soyadı, yayın yılı, yayıncının adı. (Bu size dizinde hangi bilgileri saklamanız gerektiği hakkında fikir verir)

Yukarıdaki cevaplardan, dizinimizdeki şemanın bir şekilde buna benzemesi gerektiğini söyleyebiliriz.

// Bu tam eşleme değil, sadece örnek için

            "yearOfPublish":{
                "type": "integer"
            },
            "author":{
                "type": "object",
                "properties": {
                    "firstName":{
                        "type": "string"
                    },
                    "lastName":{
                        "type": "string"
                    }
                }
            },
            "publisherName":{
                "type": "string"
            }
        }

Yukarıdakilere ulaşmak için Kitaplar adlı bir dizin oluşturabilir ve çeşitli türlere sahip olabiliriz.

Dizin: Kitap

Türler: Bilim, Sanat

(Veya daha fazla kitabınız varsa Teknoloji, Tıp Bilimi, Tarih, Dil gibi birçok tür oluşturabilirsiniz)

Burada dikkat edilmesi gereken önemli şey şemanın benzer olduğu, ancak verilerin aynı olmadığıdır. Ve diğer önemli şey, sakladığınız toplam verilerdir.

Yukarıda bir Dizin farklı türleri için ne zaman gitmek yardımcı olacağını umuyoruz, farklı şema varsa farklı dizin düşünmelisiniz. Daha az veri için küçük dizin. büyük veri için büyük dizin :-)

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.