Як керувати мільйонами користувачів?

Я збираюся запустити щось дійсно велике. Мені потрібно підготувати сервер і базу даних.

Я хотів би згрупувати кожен набір із 100 000 користувачів в окремі таблиці користувачів, але я не знаю, як пов’язати одного користувача, який намагається увійти до відповідної таблиці користувачів.

Наприклад, як я можу знати, що користувач jay@mail.comпов’язаний із таблицею користувачів №36?

Чи було б так само мати 10 мільйонів користувачів в одній таблиці користувачів або 100 з 100 000?

Як працює Facebook? Не можу повірити, що у них буде одна глобальна таблиця користувачів з 950 мільйонами записів.

Завтра у вас не буде мільярда користувачів, і MySQL може без проблем обробити кілька мільйонів рядків. У мене в користувальницькій таблиці 5 мільйонів користувачів, і мені довіряють, це навіть не в моєму радарі.

Не турбуйтеся про сегментування , поки не потрібно , щоб зробити це. Ви намагаєтесь передчасно оптимізувати проблему, яка може бути, а може і не існувати, і в процесі ви сильно скалічите темпи, з якими можете внести інновації. Будьте швидкі, щоб запустити і знайти проблеми, як вони приходять. Ви не можете заздалегідь передбачити, якими будуть проблеми зі масштабуванням.

Коли і якщо ви коли-небудь досягнете такого масштабу, у вас буде досить грошей і ресурсів, щоб кинути на цю проблему.

Я не впевнений, що зовнішні консультанти будуть кращою підтримкою для вашої компанії, якщо ви збираєтеся обробляти дійсно великі набори даних і вам потрібно починати з місця. Будь ласка, не зрозумійте мене неправильно, але якщо хтось накрутить проект із такою кількістю клієнтів, це вплине на PR на вашу компанію.

Щодо 10М кортежів в одній таблиці, якщо у вас є хороша індексація, це буде добре. Нам потрібно зберігати кілька кортежів 100М в одній таблиці (продані предмети), що чудово працює на великому оракулі 11г

Ось публікація з 2010 року з картою дизайну db design facebooks: Дизайн баз даних Facebook

Ви можете прочитати документацію mysql про такі типи розділів: MySQL документація: Partinioning

MySQL підтримує такі типи:

RANGE розділення. Цей тип розподілу присвоює рядки розділам на основі значень стовпців, що знаходяться в заданому діапазоні. Див. Розділ 18.2.1, "Розділ RANGE".

СПИСОК розділ. Аналогічно поділу RANGE, за винятком того, що розділ вибирається на основі стовпців, що відповідають одному з набору дискретних значень. Див. Розділ 18.2.2, "Розділення списку".

HASH розділення. При такому типі розбиття розділ вибирається на основі значення, поверненого визначеним користувачем виразом, яке діє на значення стовпців у рядках, які потрібно вставити в таблицю. Функція може складатися з будь-якого вираження, дійсного в MySQL, який дає неотримне ціле значення. Розширення до цього типу, LINEAR HASH, також доступне. Див. Розділ 18.2.3, "Розбиття на HASH".

КЛЮЧОВИЙ розділ. Цей тип розподілу схожий з розділенням HASH, за винятком того, що подаються лише один або кілька стовпців, які підлягають оцінці, і сервер MySQL забезпечує власну функцію хешування. Ці стовпці можуть містити інші цілі значення, оскільки функція хешування, надана MySQL, гарантує цілий результат незалежно від типу даних стовпців. Розширення до цього типу, LINEAR KEY, також доступне. Див. Розділ 18.2.4, "КЛЮЧОВИЙ Розбиття".

Перш за все, не розділяйте користувачів на окремі таблиці. Це зробить речі складними та безглуздими. Бази даних, такі як MySQL та інші, можуть без проблем працювати з базами мільйонів записів у тій самій таблиці (з налаштуванням ПРАВНИХ КЛЮЧІВ). Використовуйте базу даних AUTO_INCREMENT І PRIMARY унікальне ключове поле для кожного користувача (в головній таблиці користувачів), тому кожен запис є унікальним (UID). Потім в інших таблицях, на які ви посилаєтесь, використовуйте цей унікальний ідентифікатор. Потім переконайтеся, що в кожній таблиці, яку ви встановили як ПЕРВІЙНИЙ КЛЮЧ, це прискорить обробку інформації на сервері баз даних. Ви можете дізнатися з Drupal CMS, як він зберігає інформацію про користувача. Тестували протягом більше 10 років мільйони користувачів та дуже великі компанії (використовуються великими медіа-компаніями, урядом, навіть найбільшими банками світу). На www.drupal. org Ви знайдете понад 1,6 мільйона сторінок (вузлів), що зберігаються в одній таблиці, і вона має більше мільйона унікальних відвідувачів на місяць, і веб-сайт працює без збоїв. Все про належну оптимізацію та конфігурацію.

Після 10 мільйонів записів, якщо ви не задоволені продуктивністю (після належної оптимізації та змін конфігурації db), ви можете вирішити, чи дійсно ви хочете розділити користувачів за різними таблицями. Таким чином, ви можете фактично розширити свою функціональність, додавши нову таблицю, яка містить інформацію про те, де зберігаються записи користувачів: UID та ім’я_таблі. Тоді в будь-якій іншій таблиці запитуйте цю інформацію, ця таблиця шукатиме потрібну таблицю. Але я дійсно раджу вам створити одну велику таблицю для користувачів, якщо у вас більше 10-100 мільйонів записів. Але це не значно покращить продуктивність (бази даних розроблені для роботи з величезними даними). Краще зберігати інформацію просто. Зазвичай компанії просто вирішують інший сервер баз даних (головний і раби), а інший, то вони ' знову працюємо з функцією збалансування навантаження. Якщо у вас буде ці 10 мільйонів користувачів, ви можете заплатити за інший сервер db, правда?

Дивіться приклад userсхеми таблиці у файлі user.install .

Як підказують інші відповіді, розділяти користувачів на кілька таблиць не дуже добре. Більшість баз даних з індексами на userid можуть обробляти мільйони рядків. Однак затримка на запит може збільшуватися залежно від загальної кількості записів в індексі. Поки набір даних невеликий, ви можете керувати однією таблицею в звичайних базах даних.

Я спробую піднести іншу ідею і для вашого майбутнього розгляду, якщо ви зросте набагато більше мільйона записів або близько того. З такою великою кількістю клієнтів, ви не хочете простоїв тощо. Отже, існує купа баз даних noql, які ви можете поглянути. Вони зроблять заточку за вас замість того, щоб ви самі керували заточуванням з програми. Вони також дадуть надмірність даних і, отже, більше часу роботи. Facebook і всі вони активно використовують memcache тощо для свого кешу. Але я не впевнений, що вони використовують для свого постійного магазину.

Одне важливе, що ви повинні зауважити, - це те, що ви не можете приєднуватися тощо до баз даних nosql. Отож, сплануйте свій користувальницький шафа і вирішіть. Якщо об'єднання та транзакції з декількома записами є необхідністю для вас, то бази даних nosql не для вас.

чому б не розділити на основі алфавітного діапазону? Якщо у вас будуть мільйони користувачів, створіть окрему таблицю для кожної літери або пари літер (таблиця 'a' для користувачів, ім’я користувача яких починається з 'a'). Спочатку це буде набагато більше, але оскільки ви очікуєте великої бази даних і хочете мати можливість розрізнити, яку таблицю слід використовувати конкретному користувачеві - я думаю, що алфавітний порядок - це очевидний і найпростіший вибір.