Инфраструктура для высококонкурентных, высокозаписывающих БД

Мои требования:

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

В настоящее время мы максимизируем высокопроизводительный, очень большой экземпляр на 700 соединений. Все 8 ядер максимально. Мы думаем, что это количество одновременных подключений, так как память в порядке. Сама запись очень проста (проверки медленные вещи). Чтобы масштабировать до 3000, нам нужно перейти на несколько серверов, текущие параметры:

• MySQL Sharding
• MongoDB Cluster
• Cassandra
• Hadoop & MySQL (кэши Hadoop, одиночный дамп в MySQL)
• MongoDB и MySQL (вместо Hadoop мы используем mongo для кеширования)

Чтобы справиться с таким количеством соединений, возникает ряд вопросов:

1. Может ли MySQL Sharding обрабатывать параллельные соединения?
2. Может ли какой-либо один мастер обрабатывать эти параллельные соединения, или лучше использовать мульти-головку, например, Mongo?

Я прошу прощения, если я плохо описываю свою проблему. Пожалуйста, задавайте вопросы.

Если вы используете MySQL в качестве основной базы данных, вы можете рассмотреть возможность использования топологии Star через MySQL Replication.

Теперь, прежде чем вы скажете UGHHH, ROFL и OMG для MySQL Replication, выслушайте меня.

Звездная топология позволяет вам записывать на один сервер БД (называемый Distribution Mster [DM]) и отправлять команды SQL на несколько серверов БД. Как вы настраиваете такую ​​инфраструктуру БД?

Вот описание

У вас есть 5 серверов БД (сервер A, B, C, D, E)

Сервер А

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

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

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

Я уже писал посты по этому вопросу

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

Чтобы сохранить MySQL Replication в отличной форме

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

MySQL Cluster может быть другим подходом к шардингу. Проверьте пост здесь .

Я также большой поклонник Cassandra, но это во многом зависит от вашей модели данных и запросов, которые вы хотите выполнить. Кассандра молниеносно записывает, потому что они всегда последовательны на диске.

Если вы собираетесь работать в нескольких направлениях (что вам, вероятно, понадобится, если вам действительно нужны 3К активные соединения), я бы, вероятно, посмотрел на Риака или, возможно, Кассандру. Это зависит от того, насколько хорошо они подойдут для вашего приложения, но от того, что вы описали, я думаю, что оно подойдет для чего-то вроде Riak.

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

Да, и хотя я думаю, что вы могли бы попытаться масштабировать что-то подобное по вертикали (один узел обрабатывает все 3К-соединения), я не думаю, что вы можете сделать это в облаке.

Если это вариант для вашего конкретного приложения, возможно, вы можете использовать какой-то асинхронный способ записи данных в вашу базу данных (рабочая очередь, пакетные вставки ...) и / или удалить множество клиентских подключений из вашей базы данных с некоторым прокси-сервером впереди. ,

С помощью шардинга вы можете нормально масштабировать (2x db-сервера == 2x соединения), но это сильно зависит от природы вашего набора данных и от того, как вы можете разделить его на шарды.

Лично я предпочитаю MongoDB за простоту администрирования, масштабируемость и простоту использования. Кроме того, если мне на самом деле не нужна СУБД, я собираюсь использовать no-SQL.

С учетом сказанного выберите БД, наиболее подходящую для вашего приложения. Если вам нужны транзакции или вы не можете создать свое приложение без объединений (или это просто логично для них), тогда используйте СУБД (MySQL, PostGres и т. Д.)

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

Наконец, я бы не использовал MongoDB для кэша MySQL; используйте Memcached для этого.

Redis - это также хранилище значений ключей в оперативной памяти, которое хорошо подходит для обработки определенных вариантов использования. На blog.agoragames.com есть некоторые записи в блоге, в которых описаны некоторые варианты использования.

Вы также должны проверить CouchDB, если вы думаете о No-SQL. Просто имейте в виду, что это требует регулярного обслуживания, чтобы снизить использование диска. (Он торгует скоростью и удобством для использования диска ...)

Наконец, планирование емкости не легко предсказать. Вы должны проверить в максимально реалистичных условиях и быть готовыми к исправлению на основе того, что вы видите. К сожалению, «Компьютерные науки» - это столько же искусство, сколько наука.