Масштабируемость базы данных с приложением для записи
У меня есть приложение с тяжелой записью. Приложение лучше всего подходит для опросов - клиент создает пользовательские анкеты, которые сохраняются в базе данных. Большинство запросов от их пользователей, отправляющих эти формы. Позже наши клиенты делают сложные отчеты и графики по этим представлениям.
Убедиться, что наш сервер приложений (PHP) и веб-сервер (Nginx) масштабируются довольно просто, проблема заключается в масштабировании сервера базы данных на несколько серверов.
Многие приложения более тяжелы для чтения, поэтому обычно у вас есть настройка репликации "ведущий-ведомый", при которой все записи отправляются на один ведущий, но чтения распределяются на ведомые. Для нас это не работает, потому что мы пишем большую часть времени.
Я видел упоминание о настройке мастер-мастер, но обычно это связано с автоинкрементными первичными ключами. Решение обычно состоит в том, чтобы один сервер делал нечетные числа, а другой - четные. Я хочу избежать этого.
В некоторых похожих вопросах я упоминал о Tungsten Replicator и о том, как он дает вам гораздо больше гибкости при репликации. Поможет ли это мне вообще? Какие преимущества это даст мне, что не может обеспечить встроенная репликация MySQL?
Существует также MySQL Cluster, но это, как правило, сталкивается с очень большими базами данных и сложными запросами (объединениями). Мне нужно иметь возможность запускать сложные отчеты, так что это, вероятно, не будет работать для меня.
Я ищу избыточность, автоматическое переключение при сбое, распределение запросов и целостность данных.
Существуют ли другие RDMS, которые предоставляют лучшие решения, подходящие для Интернета?
3 ответа
Нет такой вещи, как Великий Объединенный Макет Базы Данных. Если есть пользовательские вопросники, то там действительно должны быть пользовательские таблицы. В противном случае вы на пути к монструозности VARCHAR(128)-with-no-primary-keys из thedailywtf.com, которая содержит не одну таблицу из 200 столбцов, которая неэффективна, не поддерживается и в будущем причинит вам вред.,
Возможно, следует рассмотреть вопрос о разбиении, как рекомендует toppledwagon, но сначала дважды проверьте, рационально ли разработана ваша база данных. Если это не нормализовано, то есть очень хорошая, желательно подкрепленная тестированием, причина, почему это не так. Если в нем сотни таблиц, возможно, это неправильно. Если у него одна таблица, это определенно неправильно. Посмотрите, как вы можете разделить вашу проблему на независимые множества. Вы потратите больше усилий заранее, но система будет лучше для этого.
Миллион строк, с, скажем, 2 КБ данных на строку (что представляется большим количеством символов для опроса), составляет 2 ГБ памяти. Если вы можете добавить немного больше оборудования к вашей проблеме, возможно, вы сможете сохранить свои данные в оперативной памяти?
Что приводит к следующему вопросу: какова ваша нагрузка в абсолютных числах? Клиентские запросы в секунду, переведенные в операции ввода-вывода в секунду, разделенные на операции чтения и записи в секунду, сколько гигабайт данных и с какой скоростью роста? Как ваша нагрузка зависит от количества запросов? Линейно? Экспоненциально? Вам не нужно публиковать свои данные, просто запишите их и подумайте об этом. Что это сегодня, как вы думаете, это будет выглядеть через год или два.
Википедия говорит, что диск SAS со скоростью 15 000 об / мин даст вам 175-210 операций ввода-вывода. Сколько вам нужно в RAID 10, чтобы удовлетворить вашу текущую и прогнозируемую нагрузку? Насколько велик ваш набор данных? Сколько дисков вам нужно, чтобы соответствовать вашему набору данных (вероятно, намного меньше, чем для удовлетворения требований ввода-вывода). Будет ли покупка пары (или дюжины) SSD оправдана? Локальное хранилище будет в порядке, или вы собираетесь насытить две оптоволоконные линии 8 Гбит в подсистему хранения высшего класса?
Если в настоящее время вам требуется 1 тыс. Операций ввода-вывода, но в RAID 5 есть три жестких диска со скоростью 10 тыс. Об / мин, то ваше оборудование не сможет удовлетворить ваши требования. OTOH, если ваше приложение получает пользовательский запрос в секунду и ставит на колени 32-ядерный 256 ГБ оперативной памяти, поддерживаемый хранилищем корпоративного класса, то, скорее всего, проблема заключается не в аппаратных возможностях.
мастер-мастер настройки, но это обычно попадает в загадку с автоматически увеличенными первичными ключами
Нет - вы просто настраиваете автоприращение-приращение и авто-приращение-смещение, чтобы избежать коллизий
Решение обычно состоит в том, чтобы один сервер делал нечетные числа, а другой - четные. Я хочу избежать этого.
Зачем? Суррогатные ключи по самой своей природе не связаны с данными, которые они индексируют. Присвоение значения таким ценностям очень опасно.
Беглый взгляд на предоставленную вами ссылку Tungsten мало что говорит о том, что она делает, - у нее есть ряд неточностей (например, "вы можете выполнять репликацию с несколькими мастерами, что больше, чем то, что вы можете делать с собственной репликацией MySQL"). В том же пункте говорится, что он не может справиться с конфликтами. Я не уверен в полезности этого продукта.
Предполагая, что репликация master-master (с федерацией или без федерации для ограничения репликации) не удовлетворяет вашим требованиям (но вам необходимо пересмотреть свои представления о типах полей с автоинкрементом), вы можете разделить данные между собственными кластерами с помощью mysqlproxy или используйте базу данных nosql.
Это звучит как хороший случай для шардинга. Если данные одного опроса не нуждаются в немедленном доступе к данным другого опроса, то защитить ваши данные будет легко. Вы создадите базу данных, которая в основном имеет ключ идентификатора пользователя, который указывает на базу данных Survey. Затем вы можете настроить несколько баз данных Survey. Надеюсь, вы также захотите установить их в реплицированные кортежи. Ваше приложение будет нуждаться в доработке.
Запускайте свои отчеты и делайте соединения в программном обеспечении. Если это тоже вариант, то шардинг - это путь.