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