Facebook gibi mesajlar için Veritabanı Tasarım [kapalı]

11 Cevap php

Şu anda PHP / MySQL yeni bir sistem planlama ve benim veritabanı ben deposuna planlıyorum veri miktarını işleyebilir emin olmak istiyorum duyuyorum. Benim yeni projenin özelliklerinden biri Facebook gibi bir "mesajlar" özelliğidir. Ben son kullanıcı için mümkün olan en iyi deneyimi oluşturmak emin olmak istiyorum. Web sitesi sonunda topluca mesajlarının potansiyel olarak milyonlarca kullanıcı ile 1000 idare edecektir. Ne veritabanı tasarımı için en iyi yaklaşım olacaktır? MySQL kullanmak için bile doğru veritabanı mı?

11 Cevap

MySQL sürece doğru size veritabanı tasarımı gibi milyonlarca veya kayıtları yüz milyonlarca hiçbir sorun vardır.

Oldukça geniş bir tanım olduğunu söyleniyor, bir "Facebook gibi mesajlar bulunmaktadır". Genellikle, (yani mesaj tablosunda bir userId sütun var) onu yaratan kullanıcı her mesajı bağlanan bir messages tablo tanımlamak olacaktır. Iletiler birden fazla kullanıcıya gitmek isterseniz, messageId oluşan çoklu kayıtları saklamak ve bir {[(4) ile 1-çok ilişkisini tanımlayan bir message_recipients tablo var }]. Bu tablolara uygun dizinleri eklemek ve orada yol% 80 demektir.

Söyleniyor, bu geri kalan% 20 bir katil olabilir. Ne yazık ki, veritabanı yapmanız gereken başka ne belirlemek için gidiyor ve bu yargılar yapılabilir önce Eğer uygulama hakkında çok daha fazla ayrıntı sağlamak gerekiyor nasıl kullandıkları. Örneğin, ana tablo nispeten küçük tutar otomatik arşivleme çözümü bulundurun isteyebilirsiniz, ve gerekirse ulaşılabilir yedek tabloları eski verileri taşır. Muhtemelen hemen bu gerekmez, ancak gelecekte yardımcı olabilir.

Facebook MySQL ile başladı ve 100 milyondan fazla kullanıcı için gelen veri 7TB vardı onlar sadece Cassandra taşındı.

Kaynak: Lakshman, Malik: Cassandra - A Decentralized Structured Storage System.

(Elbette ki milyonlarca bile büyük olmaya yakın gelmiyor) büyük miktarda veri işlemek için planlıyorsanız, o zaman bir datbase profesyonel kiralama. Büyük veri kümeleri için verimli ve etkili veritabanı tasarımı karmaşık bir konudur ve bir uzman gerektirir.

Tasarımı iyi ve tasarımı oldukça fazla diğer modern datbase gibi, kötü bir kabus olacak eğer sorunuzun cevabı evet mysql kolayca kayıtları milyonlarca işleyebilir.

If Eğer performans verilerinin miktarı ile logarithmically bozulabilir, doğru veritabanı tasarımı. Diğer bir deyişle, sizin sorguları yürütme için zamanlı veri miktarı çok daha yavaş büyüyecektir.

Bu amaca ulaşmak için, bir şeyler bir dizi hakkında disiplinli olmak gerekir:

  • Sizin veritabanı tasarımı sağlam olmalıdır. Anlamak ER modeling ve normalleştirme esastır. Böylece anatomy of indexes ve diğer fiziksel veri yapıları anlamaktır.
  • Eğer güzel bir normalize veritabanı var sonra bunun bazı "kenarları" mantıklı performans nedenlerle tamamen denormalized olmalıdır eğer, düşünün.
  • Throughout this whole process, keep in mind what kind of queries will your client application1 do:
    • Buna göre tasarım indeksleri - indeks özellikle sorguları için size gerekir biliyorum,-indeks üzerinden yapmayın!
    • Böyle vekil tuşları vs doğal kaynakların kullanımı ve vs tanımlayıcı olmayan ilişkileri belirleme gibi bazı tasarım kararları, ihtiyacınız Joın miktarını etkileyebilir.
    • Kümelenmiş aralığı taramaları, index-only scans vb veritabanı tasarım dost tutmak için çalışın
  • Gibi kullanın DBMS özel mekanizmalar, clustering, bölümleme, anahtar sıkıştırma, sizin yararınıza görüşlerini (vb.) Gerçekleşmiştir. DBMS Eğer gerekli gördükleri bazı mekanizması desteklemiyorsa, DBMS geçmek için korkmayın! Eğer ikincil dizin gerekiyorsa Örneğin, InnoDB tables are always clustered, PK üzerinde sorgularken bir avantaj, ancak hangi bir dezavantaj olabilir. Eğer iki tablo kümelenmiş ve yığın tabanlı ihtiyacınız varsa, (örneğin Oracle veya MS SQL Server gibi) hem de onları destekleyen bazı DBMS kullanmak. 2
  • Dikkatli istemci uygulama kodu. Dinen kullanım parametreleri ve sorgu preparation bağlı değil - sadece SQL ayrıştırma ve sorgu planlama yükünü en aza indirmek olacak, ama aynı zamanda SQL enjeksiyon dayanıklı olacak! ORMS ve kütüphaneleri sık sık elle yapıyor sizi koruyacak, ancak yine "kapakların altında" oluyor anlamak gerekir.
  • Ve son ama en az değil, varsayımlar üzerine röle yok - measure yerine! Veritabanı performansı ince (ve oldukça karmaşık) dengeleme hareket olabilir ve bazı kararların etkisi hemen belirgin olmayabilir

Eğer doğru tüm bu yaparsanız, bir "klasik" DBMS yeterli olmaktan durur önce verilerin gerçek Facebook'un miktarda yaklaşım gerekir. Kullanıcılar ve milyonlarca veya mesajlarının 1000'ler bile bu bağlamda "büyük" olarak nitelemek değil.

DBMS perspektifinden 1 A "müşteri" -., Bu aynı zamanda bir orta katman olabilir

2 MyISAM da kümelenmiş değil, ancak ciddi sınırlamalar zaten normal kullanımdan kaynaklanan diskalifiye gerektiğini (bu işlemlerin yokluğu gibi) desteği gelmiştir.

Eğer bir bütçe üzerinde iseniz, MySQL ile başlar ve Zend :: DB gibi veya daha yüksek bir düzey Doktrin bir sistem kullanın.

Bu kolay başında senin DBMS seçmek sonra DMBS geçiş yapmak daha önemlidir.

Sürece kurulum gibi tablolar ilişkisel olması ve tablolar arasındaki ilişkileri ayarlamak için, MySQL ince olmalıdır.

Ben de Postgres önerebilir?

Eğer öğrenmek istediğiniz ne çok hassas değildir. Tamam. Ben size bazı tavsiyeler vermek için çalışacağım.

  1. Normalleştirme
  2. Endeksleri
  3. Yüksek yük altında tablolar MyISAM
  4. Denormalizasyon (sic!), ama sen ne yapıyorsun anlamak gerekir
  5. Sharding
  6. Esneklik için minimalist DB katman

Eğer "benim mysql tablo bir mesaj sistemi gibi bakmak gerekir" demek, benim mesaj sistemi aşağıdaki sütunları kullanın:

message_id
fromuser
fromview
fromstatus
touser
toview
tostatus
title
text
poston
thread

Message_id Açıkçası, auto_increment olduğunu. Fromuser ve touser açıktır. Fromstatus ve tostatus aynı şekilde silinmiş, tasfiye, taslak, ve, aktiftir. Fromview ve toview 'evet' ve 'hayır' için ayarlanır. Başlık, metin, ve 'poston' tarih açıktır. Konu html formları ve mesaj ekranı komut bağlı olarak sizin açınızdan biraz çaba alabilir.

Formunuz için, "için:" dayalı bir foreach döngü oluşturmak alanında ve her alıcı için bir kopyasını kaydedin.

Ben bu mesaj sistemi milyonlarca tutmak için bekliyoruz, ama milyonlarca uzakta muhtemelen bir kaç yıl olduğunu. Ben küçük ve basit tutuyorum.

Sharding sizin "geniş" tabanlı gereksinimleri için ... Ben veri adil bir miktar ile ele alınmıştır ve bir milyar kayıtlarını barındıran çok sayıda tablo vardı kadar bile bölümlenmiş tablolar ve shard uygulanmasını kabul etmedi kesinlikle gerekli değildir (daha sonra bu olabilir katılmadan ) biraz yavaş olsun. Akıllı tuşları ile indeksi tablolar, ve hatta dar tabloları tutmak ve sorguları boş döner kendinizi rahatlatmak için bir eav tipi yapıyı kullanarak düşünebilirsiniz.

Yarı uykuda yüzden yazım hataları göz ardı ederken yukarıda yazılmış ;)

I'd say read about object oriented databases as well as nosql systems, it is a very interesting concept, actively used by famous frameworks like Ruby on rails, which allows you to worry less about your data, since you can simply dump your object straight into the database, I know it is a little off topic but less complex databases mean easier transition into scalable systems, and I'm just spreading awareness

Ancak takas gibi geçinmek zor sorunlara cevap bulmak için yapar ilişkisel veritabanları gibi bir güçlü userbase, ve onu kullanarak içine adapte etmek gereken bir zaman eşit derecede uzun bir miktar olan, ama düşünmeden verileri kapsayan değil, bir Eğer etrafında daha az yardım olmadığından çözmek için zor olacak şişe boyunları ve performans sorunları yüz zaman iş mantığı yazma her aşamada veritabanı tasarımı, ancak daha sonra, sahip olmak inanılmaz bir şey olduğunu ve geliştirme süresini hızlandırır.

MySQL üzerinde çalıştık değil ama SQL Server ve Oracle profesyonelce çalıştık. Ben herhangi bir yüksek performanslı bir sistem için Oracle öneriyoruz.

etiketler