3 milyon kayıt anahtar / değer biçiminde nasıl saklanır?

3 milyon ürün hakkında temel bilgileri saklamamız gerekiyor. Şu anda bilgi üç ayda bir güncellenen bir 180 MB CSV olduğunu.

Günde yaklaşık 30.000 sorgu olacak, ancak sorgular çok basit bir anahtar değer deposudur. Sadece ürün kimliğine bakmamız ve geri kalan bilgileri görüntülememiz gerekiyor (hepsi tek bir kayıtta olacak).

Bu web içindir, bu nedenle hızlı performans çok önemlidir.

Gerçekten ilişkisel bir veritabanına ihtiyacımız olmasa da MySQL kullanmalı mıyız? Her üç ayda bir 3 milyon statik html dosyası oluşturmalı mıyız? Amazon S3 veya Rackspace Cloud Files gibi her ürün için tek satırlık bir CSV saklamalı mıyız? Bunu yapmanın en iyi yolu nedir?

MySQL çok yaygın olarak desteklendiğinden ve bu gerçekten oldukça önemsiz bir şey olduğundan, onunla devam etmenizi öneririm. Sunucuda en az birkaç GB bellek olmadığı sürece, bir bellek içi sistem kullanmak yerine MySQL ile çalışmayı öneririm.

Verilerinizi MySQL veya başka bir şey olsun, bir veritabanına koymaya başladığınızda, bunun için daha fazla kullanım alanı bulacağınızı göreceksiniz. Şu anda yalnızca anahtar / değer çiftlerinden bahsediyorsunuz, ancak ürünlerinizle ilgili diğer verilerin bir yerde saklanması gerekiyor. Bu bir veritabanında değilse, veri depolama çok verimli olduğunu düşünemiyorum.

Ne yaparsan yap, yok o üç milyondan dosyaları oluşturun. Burada, bu kadar çok dosyanın yarattığı sorunlardan kaynaklanan bir dizi soru gördük.

Bu tür görevler için optimize edilmiş özel Anahtar-Değer tipi NoSQL veritabanı kullanabilirsiniz . Bir bak bakalım:

• Redis - Redis açık kaynaklı, gelişmiş bir anahtar / değer çifti deposudur. Anahtarlar dizeler, karmalar, listeler, kümeler ve sıralı kümeler içerebileceğinden, genellikle bir veri yapısı sunucusu olarak adlandırılır.
• MemcacheDB - MemcacheDB, kalıcı olarak tasarlanmış dağıtılmış bir anahtar / değer depolama sistemidir.
• diğerleri (bu tür listelerden birini burada bulabilirsiniz: http://nosql-database.org/ )

Tabii MySQL veya başka bir ilişkisel veritabanı, ancak çözüm kullanabilir özel hariç, (aksi ilk etapta bunları tasarlarken ne anlamı daha iyi olması gerekiyordu verilerin anahtar-değer türü için tasarlanmış muhtemelen çok daha küçük olacak gerçeğini (RAM ve HDD açısından) çözümü).

Ve şimdi tamamen farklı bir şey:

Verilen:

• 180MB / 3M ürünler = ortalama 62 bayt / ürün.
• Günde 30.000 sorgu = saniyede 0.34 sorgu
• Üç ayda bir güncellenen = esasen statik veriler

Kutunun dışında çözüm:

Her ürünü bir TXT kaynak kaydı olarak dökün ve DNS'de saklayın, örn:

$origin products.example.com.

product_1_name IN TXT "product 1 description"
product_2_name IN TXT "product 2 description"
...
product_3000000_name IN TXT "product 3000000 description"

Yararları:

• son derece güvenilir ve güvenilir (zaten her gün ona güveniyorsunuz)
• hemen hemen her platform üzerine inşa edilebilir
• hemen hemen her dilde DNS sorguları için şu veya bu şekilde destek bulunur
• açık kaynaklı ve ticari sunucular farklı arka uç veritabanlarını destekler
• önemsiz bir şekilde çoğaltılabilir (sadece birden çok ad sunucusu belirtin)
• bir düzine sunucuda çoğaltılmış olsa bile atomik güncellemeleri işler
• veri bütünlüğünü sağlamak için kriptografik olarak imzalanabilir
• İkinci oranları başına büyüklüğü daha yüksek sorgunun siparişleri (10.000 sorguları işleyebilir ikinci kolayca emtia donanımla işlenir)

Bunun kötü bir fikir olabilmesinin nedenleri:

• verileri aramanız gerekir (DNS tamamen anahtar / değer aramasıdır)
• verileri gizlemeniz gerekir (DNS'nin gizliliği yoktur)

MyISAM ile MySQL ve bazı iyi dizinler bunun için mükemmel geliyor. Tabii ki diğer seçenekler bir sürü vardır, ancak MySQL çok yaygın (evrensel değilse) herhangi bir ticari web barındırma desteklenmektedir. İstediğiniz hıza bağlı olarak, memcached da bakmaya değer olabilir , ancak her anahtar / değer çiftinin boyutunu bilmeden, 3 milyonu bellekte saklamak 180Mb CSV dosyasından daha kötü bir fikir olabilir (oh bekleyin, bu 180Mb CSV dosyası, bu yüzden ne kadar büyük olduklarını biliyoruz.

Sen do not o kötü dosya sistemini zarar edecek, 3 milyon statik HTML dosyaları istiyorum. Tek hatlı bir CSV, S3'te bile aynı soruna sahip olacak. Kimse bir klasörde 3 milyon dosya istemiyor.

Perl5'in başlangıcından bu yana kalça olmasa bile, tam olarak bu tür şeyleri yapan Berkeley Veritabanını kullanabilirsiniz. Berkeley yalnızca anahtar / değer çiftlerini destekler ve tüm db'yi bir karmaya bağlar ve ona bu şekilde erişirsiniz.

Rafınızda oturan eski Perl referanslarının birçoğunda Berkeley kullanımı veya BerkeleyDB CPAN Modülü için Perldoc'u deneyin . Genellikle Berkeley DB kullanmaktan kaçınırım (işverenimin belirgin bir şekilde oynadığı çok eski bir koda sahip olmasına ve DB'lerin bazıları sizinki kadar büyük olmasına rağmen), çünkü verileriniz daha karmaşık hale geldiğinde eğlenceli değildir.

Sorunuzu amazon S3 olarak işaretlediniz.

Dikkatinizi Amazon SimpleDB adlı diğer ilgili ürünlerden birine çekmek istiyorum.
SimpleDB veri modelinin uygulama türünüze iyi uyduğu anlaşılıyor.

Bu bir fiş değil, özellikle Amazon bulut hizmetlerini kullanmayı planlıyorsanız bakmaya değer.

SDB veri modeli bir elektronik tabloya benzer.

Daha fazla bilgi için buraya bakın: http://aws.amazon.com/simpledb/ Ve veri modeli: http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/

180mb veri herhangi bir ilişkisel veritabanı tarafından kolayca ele alınabilse de, MongoDB'yi şiddetle tavsiye ederim ( http://www.mongodb.org/) MySQL, Redis, MemcacheDB ve diğer daha basit anahtar / değer depoları veya ilişkisel veritabanlarının üstünde. Bunun nedeni, bu tür bir sorun için, MongoDB'nin kullanmak için en hızlı, en etkileyici sistem olması ve şema kısıtlamaları olmadan süper hızlı dinamik güncellemelere izin vermesi, böylece belgelerinizin farklı biçimlere sahip olmalarıdır. Geçen gün guardian.co.uk adresinden bir sunum yaptım ve tüm ilişkisel veritabanlarını yasaklamak ve MongoDB'yi yalnızca haberlerini sunmak için kullanmak için bir politika kararı aldılar. Web sitelerinin ne kadar hızlı olduğu ve 1995'ten beri çevrimiçi olduğu hakkında bir fikir edinebilirsiniz (İngiltere'deki en eski çevrimiçi gazete). İlişkisel veritabanları nedeniyle geçmişte her türlü darboğazdan geçtiler. 180mb için, MongoDB bellekten her şeyi sunacak, bu nedenle alt ms yükleme süreleri söz konusu olacak.

Günde yaklaşık 30.000 sorgu olacak, ancak sorgular çok basit bir anahtar değer deposudur. Sadece ürün kimliğine bakmamız ve geri kalan bilgileri görüntülememiz gerekiyor (hepsi tek bir kayıtta olacak).

Sorgularınızın sadece basit anahtar aramaları olduğunu söylediniz, ikili arama ile en kötü durumda 21 yinelemeye ihtiyacınız var, karma anahtarlarla sorgularınız daha da hızlı. Üç milyon kayıt, birleştirmelerden (veya diğer kartezyen ürün türü işlemlerden) ve doğrusal aramalardan kaçındığınız sürece küçüktür .

Hemen hemen her şeyin yoluna gireceğini söylemeye cesaret edebilirim. Yükünüz 30000 sorgu / gün (yükünüzün gün boyunca sabit olduğu varsayılarak) her 20 saniyede bir tek sorgunuz olduğu anlamına gelir; bu çok kötü değil.

Öncelikle en çok aşina olduğunuz teknolojiyi uygulamanızı ve daha sonra bunun gerçekten sistemin darboğaz olup olmadığını ölçmenizi öneririm.

Bunu yapmanın en iyi yolu, verilerinizin ve sorgularınızın kalitesine ve niteliğine bağlıdır. Yeni başlayanlar için, ürünler için tek bir tabloda 180 MB veri, hangi yöne bakarsanız bakın sorun değildir. Ve günde 30 bin sorgu daha az sorun. Düzgün yapılandırılmış bir veritabanı ile, herhangi bir eski masaüstü bu yükü kaldırabilir.

Diğerleri MySQL veya noSQL veritabanı olmak üzere iki ana seçeneğinize işaret etmişlerdir.

Her bir ürün için belirli bir sayıda özelliğiniz varsa (üretici, fiyat, depo numarası vb.), En iyi seçeneğiniz bu özellikler için sütunlara sahip olmak ve anahtar / değer çiftlerinizi düz tablo biçimine dönüştürmektir, Bu tablo için birincil anahtar olarak bir ürün kimliğine sahiptir.Bu, bazı sütunlar yalnızca satırların yarısı tarafından kullanılsa bile çok iyi çalışır, çünkü çoğu ürün için tüm özelliklerini almak için yalnızca 1 sorgu çalıştırmanız gerekir. bu ürünlerle ilgili verilerdir, sanırım bu verilerinizin yapısıdır.

Öznitelikler mevcudiyet ve veri türünde büyük farklılıklar gösteriyorsa, bu senaryoyu geleneksel SQL veritabanlarından daha verimli işleyen bir noSQL veritabanı kullanmak daha iyi olabilir.

Performansla ilgili olarak: Daha önce uzun süredir web sitesine bir MySQL sunucusundan veri sağlanan bir e-ticaret şirketi için çalıştım. Bu sunucuda 2GB RAM vardı, toplam veri tabanı yakl. 5 GB boyutunda ve üstten yük altında sunucu saniyede birkaç bin sorgu işledi. Evet, birçok sorgu optimizasyonu yaptık, ancak bu kesinlikle yapılabilir.