Bagaimana cara mengelola jutaan pengguna?

Saya akan meluncurkan sesuatu yang sangat besar. Saya perlu menyiapkan server dan database saya.

Saya ingin mengelompokkan setiap set 100.000 pengguna dalam tabel pengguna yang terpisah tetapi saya tidak tahu cara mengaitkan satu pengguna yang mencoba masuk ke tabel pengguna yang sesuai.

Misalnya, bagaimana saya tahu bahwa pengguna [email protected]terkait dengan tabel pengguna # 36?

Apakah sama untuk memiliki 10 juta pengguna dalam satu tabel pengguna atau 100 dari 100.000?

Bagaimana dengan Facebook? Saya tidak percaya mereka akan memiliki satu tabel pengguna global dengan 950 juta entri.

Anda tidak akan memiliki satu miliar pengguna besok dan MySQL dapat menangani beberapa juta baris tanpa masalah. Saya memiliki 5 juta pengguna di tabel pengguna saya dan percayalah, itu tidak perlu dikhawatirkan.

Jangan khawatir tentang sharding sampai Anda perlu melakukannya. Anda mencoba untuk mengoptimalkan secara prematur untuk masalah yang mungkin atau mungkin tidak pernah ada dan dalam prosesnya, Anda akan sangat melumpuhkan tingkat di mana Anda dapat berinovasi. Jadilah cepat untuk memulai dan menemukan masalah saat mereka datang. Anda tidak dapat memprediksi sebelumnya apa tantangan penskalaan Anda nantinya.

Kapan dan jika Anda pernah mencapai skala ini, Anda akan memiliki sedikit uang dan sumber daya untuk mengatasi masalah semacam ini.

Saya tidak yakin apakah konsultan eksternal akan menjadi dukungan yang lebih baik untuk perusahaan Anda jika Anda akan menangani kumpulan data yang sangat besar dan Anda harus mulai dari awal. Tolong jangan salah paham, tetapi jika salah satu proyek gagal dengan begitu banyak pelanggan, itu akan berdampak PR pada perusahaan Anda.

Mengenai 10M tupel dalam satu tabel, jika Anda memiliki pengindeksan yang baik itu akan baik-baik saja. Kita perlu menyimpan beberapa tuple 100 juta dalam satu tabel di sini (barang yang dijual) yang berfungsi dengan baik pada oracle 11g yang besar

Berikut ini adalah posting dari 2010 dengan peta desain db Facebooks : desain database Facebook

Anda mungkin ingin membaca dokumentasi mysql tentang tipe partisi seperti ini: Dokumentasi MySQL: Partinioning

MySQL mendukung tipe-tipe ini:

Partisi RANGE . Jenis partisi ini memberikan baris ke partisi berdasarkan nilai kolom yang berada dalam rentang tertentu. Lihat Bagian 18.2.1, “RANGE Partitioning”.

DAFTAR partisi. Mirip dengan mempartisi oleh RANGE, kecuali bahwa partisi tersebut dipilih berdasarkan kolom yang cocok dengan salah satu dari set nilai diskrit. Lihat Bagian 18.2.2, “LIST Partitioning”.

Partisi HASH . Dengan jenis partisi ini, partisi dipilih berdasarkan nilai yang dikembalikan oleh ekspresi yang ditentukan pengguna yang beroperasi pada nilai kolom dalam baris yang akan dimasukkan ke dalam tabel. Fungsi ini dapat terdiri dari ekspresi apa pun yang valid di MySQL yang menghasilkan nilai integer non-negatif. Ekstensi untuk jenis ini, LINEAR HASH, juga tersedia. Lihat Bagian 18.2.3, “Partisi HASH”.

Partisi kunci . Jenis partisi ini mirip dengan partisi oleh HASH, kecuali bahwa hanya satu atau lebih kolom yang dievaluasi disediakan, dan server MySQL menyediakan fungsi hashing sendiri. Kolom ini dapat berisi selain nilai integer, karena fungsi hashing yang disediakan oleh MySQL menjamin hasil integer terlepas dari tipe data kolom. Ekstensi untuk jenis ini, LINEAR KEY, juga tersedia. Lihat Bagian 18.2.4, “KUNCI Partisi”.

Pertama-tama, jangan pisahkan pengguna ke dalam tabel terpisah. Ini akan membuat hal-hal menjadi kompleks dan tidak berguna. Basis data seperti MySQL dan lainnya dapat bekerja dengan basis data jutaan catatan dalam tabel yang sama tanpa masalah (memiliki pengaturan PRIMARY KEYS yang tepat). Gunakan basis data AUTO_INCREMENT DAN PRIMARY bidang kunci unik untuk setiap pengguna (dalam tabel pengguna utama), sehingga setiap catatan unik (UID). Kemudian di tabel lain yang Anda referensikan menggunakan id unik itu. Kemudian pastikan bahwa di setiap tabel yang Anda tetapkan sebagai PRIMARY KEY, itu akan mempercepat pemrosesan informasi di server database. Anda dapat belajar dari Drupal CMS bagaimana ia menyimpan informasi pengguna. Diuji dalam lebih dari 10 tahun oleh jutaan pengguna dan perusahaan yang sangat besar (digunakan oleh perusahaan media besar, pemerintah, bahkan bank terbesar di dunia). Di www.drupal. org Anda akan menemukan lebih dari 1,6 juta halaman (node) yang disimpan dalam tabel yang sama dan memiliki lebih dari juta pengunjung unik per bulan dan situs web berfungsi tanpa gangguan. Semuanya tentang optimasi dan konfigurasi yang tepat.

Setelah 10 juta catatan, jika Anda tidak puas dengan kinerja (setelah optimasi yang tepat dan perubahan konfigurasi db), maka Anda dapat memutuskan apakah Anda benar-benar ingin memisahkan pengguna dengan tabel yang berbeda. Jadi Anda benar-benar dapat memperluas fungsionalitas dengan menambahkan tabel baru yang memiliki informasi tentang di mana catatan pengguna disimpan: UID dan table_name. Kemudian di tabel mana pun yang meminta informasi ini, tabel ini akan mencari tabel yang tepat. Tapi saya sangat menyarankan Anda untuk memiliki satu tabel besar untuk pengguna, kecuali jika Anda memiliki lebih dari 10-100 juta catatan. Tapi itu tidak akan banyak meningkatkan kinerja (database dirancang untuk menangani data yang sangat besar). Lebih baik menjaga informasi tetap sederhana. Biasanya perusahaan hanya memutuskan untuk server database lain (master dan slave), dan yang lain, maka mereka kembali bekerja sama dengan fungsionalitas penyeimbangan beban. Jika Anda memiliki 10 juta pengguna itu, Anda dapat membayar untuk server db lain, bukan?

Lihat contoh userskema tabel di file user.install .

Seperti yang disarankan oleh jawaban lain, itu bukan ide yang baik untuk membagi pengguna menjadi beberapa tabel. Sebagian besar database dengan indeks pada userid, dapat menangani jutaan baris. Namun, latensi per kueri dapat meningkat tergantung pada jumlah total entri dalam indeks. Selama dataset kecil, Anda dapat mengelola dengan satu tabel dalam database normal.

Saya akan mencoba untuk melontarkan ide yang berbeda juga untuk pertimbangan masa depan Anda jika Anda tumbuh lebih dari satu juta catatan. Dengan begitu banyak pelanggan, Anda tidak ingin ada waktu henti, dll. Jadi, ada banyak basis data nosql yang mungkin ingin Anda lihat. Mereka akan melakukan sharding untuk Anda alih-alih Anda yang mengelola sharding sendiri dari aplikasi. Mereka juga akan memberikan redundansi data dan karenanya lebih banyak waktu aktif. Facebook dan semuanya menggunakan memcache dll untuk cache mereka. Tapi saya tidak yakin apa yang mereka gunakan untuk toko permanen mereka.

Satu hal penting yang harus Anda perhatikan adalah bahwa Anda tidak dapat bergabung dll dengan database nosql. Jadi, rencanakan untuk usecase Anda dan putuskan. Jika bergabung dan transaksi multi-catatan adalah keharusan bagi Anda maka basis data nosql bukan untuk Anda.

mengapa tidak membagi berdasarkan rentang alfabet? Jika Anda akan memiliki jutaan pengguna, buat tabel terpisah untuk setiap huruf atau untuk pasangan huruf (tabel 'a' untuk pengguna dengan nama pengguna dimulai dengan 'a'). Awalnya akan banyak overhead tetapi karena Anda mengharapkan database besar dan ingin dapat membedakan tabel mana yang harus digunakan untuk pengguna tertentu - saya kira urutan abjad adalah pilihan yang jelas dan termudah.