Інфраструктура для БД з високим рівнем сумісності

Мої вимоги:

• 3000 підключень
• 70-85% Пишіть проти Прочитайте

Наразі ми максимізуємо високий CPU, надзвичайно великий екземпляр у 700 підключеннях. Всі 8 сердечників максифіковані. Ми вважаємо, що це кількість одночасних з'єднань, оскільки пам'ять прекрасна. Сама запис дуже проста (перевірки повільних речей). Для масштабування до 3000 нам потрібно перейти на кілька серверів, поточні параметри:

• Шардування MySQL
• Кластер MongoDB
• Кассандра
• Hadoop & MySQL (кешовані файли Hadoop, один дамп на MySQL)
• MongoDB & MySQL (замість Hadoop ми використовуємо mongo для кешу)

Щоб вирішити цю кількість з'єднань, кілька питань:

1. Чи може MySQL Sharding обробляти одночасні з'єднання?
2. Чи може будь-який єдиний майстер обробляти ці паралельні з'єднання, чи кращий варіант багатоголовок, як Монго?

Прошу вибачення, якщо я не добре описую свою проблему. Будь ласка, задайте питання.

Якщо ви використовуєте MySQL в якості основної бази даних, можливо, ви захочете розглянути можливість використання Star Topology через реплікацію MySQL.

Тепер, перш ніж сказати UGHHH, ROFL та OMG в MySQL Replication, вислухай мене.

Зоряна топологія дозволяє записувати на один сервер БД (званий розподільчим ресурсом [DM]) та відправляти команди SQL на декілька серверів БД. Як налаштувати таку інфраструктуру БД?

Ось Опис

У вас є 5 серверів БД (сервер A, B, C, D, E)

Сервер A

• У налаштуваннях реплікації MySQL це буде Master
• Особливу роль відіграє DM
• Майстер серверів B, C, D, E
• Усі таблиці використовують механізм зберігання даних BLACKHOLE (/ dev / null)
• Зберігає лише бінарні журнали
• Голий металевий верстат
• Переваги
  • Дуже швидко пише, оскільки всі таблиці в DM використовують BLACKHOLE
  • Затримка мережі є меншою проблемою, оскільки читання становить 15-30% активності БД
  • Усі раби оновлюються строго з DM

Сервери B, C, D, E

• Раб А
• Серверна база для важких SELECT
• Сервер може бути віртуальним або голим металом
• Для всіх серверів, чиї таблиці користувачів використовують механізм зберігання даних InnoDB
  • Він може працювати як гарячий режим очікування сервера БД
  • Неінструзивні резервні копії можуть бути запущені проти нього
• Для всіх серверів, чиї таблиці користувачів використовують механізм зберігання даних MyISAM
  • Налаштуйте лише за допомогою читання
  • Таблиці можуть мати свої формати рядків, перероблені для прискорення читання

Я писав повідомлення про це раніше

• /server/264374/mysql-in-star-topology/264444#264444
• /programming/5273043/mysql-in-star-topology/5781504#5781504

Щоб зберегти реплікацію MySQL у верхній формі наконечника

• Використовуйте MySQL 5.5
• Використовуйте напівсинхронну реплікацію
• Налаштуйте InnoDB, щоб залучити більше процесорів

MySQL Cluster може бути іншим підходом до загострення. Перевірте повідомлення тут .

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

Якщо ви збираєтеся йти багатоголовою (що вам, мабуть, знадобиться, якщо вам дійсно потрібні активні з'єднання 3K), я б, мабуть, подивився на Ріак або, можливо, Кассандру. Це дійсно залежить від того, що робить ваш додаток, наскільки добре вони будуть відповідати, але з того, що ви описали, я думаю, що це вписується в щось на кшталт Riak.

Однак, роздрібнений підхід виглядає досить здійсненним, якщо ви зможете знайти хороший спосіб сегментування даних і зможете мінімізувати будь-яку потребу в перехресних фрагментах. Я б тримався подалі від будь-якого з предметів кільця / зірки / ммм у mysql, і просто дотримувався б прямого заточування. Насправді, якби ви хотіли використовувати Postgres, ви могли легко прототипувати, використовуючи схеми на щось на зразок heroku, а потім розщедритися та розділити бази даних, коли вони починають переростати окремі вузли.

О, і хоча я думаю, ви могли б спробувати масштабувати щось подібне вертикально (один вузол, що обробляє всі 3K конни), я не думаю, що ви можете це зробити в хмарі.

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

За допомогою різкості ви можете загалом масштабувати великі розміри (2x db-сервери == 2x з'єднання), але це дуже залежить від характеру вашого набору даних та того, як ви можете розділити його на фрагменти.

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

Зважаючи на це, виберіть БД, який має найбільш сенс для вашої програми. Якщо вам потрібні транзакції або ви не можете створити ваш додаток без приєднання (або це просто має більше сенсу з ними), тоді використовуйте RDBMS (MySQL, PostGres тощо)

Хоча я особисто віддаю перевагу MongoDB, думка про те, що MySQL не масштабує чи не може обробити високу швидкість транзакцій, є чисто помилковою. Команда інженерії Facebook (і команда MySQL в її складі) детально описується. Також перегляньте блог команди Etsy Ops; вони також люблять MySQL.

Нарешті, я б не використовував MongoDB для кешу MySQL; використовувати Memcached для цього.

Redis - це також запам'ятовуваний ключ-значення оперативної пам'яті, який добре підходить для обробки певних випадків використання. На blog.agoragames.com є деякі записи, що описують деякі випадки використання.

Ви також повинні перевірити CouchDB, якщо ви думаєте про No-SQL. Тільки пам’ятайте, що для цього потрібна регулярна мантія щоб не використовувати її на диску. (Він торгує швидкістю та зручністю для утиліти диска ...)

Нарешті, планування потужностей передбачити непросто. Вам потрібно пройти тестування в максимально реалістичних умовах і бути готовим до ремонту на основі побаченого. На жаль, "Комп'ютерна наука" - це стільки ж мистецтво, скільки і наука.