Я столкнулся с дилеммой при выборе приложения схемы MySQL. Итак, прежде чем я начну, вот очень упрощенная картина моей базы данных:
Схема здесь: http://i43.tinypic.com/2wp5lxz.png
Одним предложением: для каждого клиента приложение собирает текстовые данные и прикрепляет теги к каждой собранной информации.
В качестве приблизительного использования каждой таблицы я ожидаю следующее:
Процесс сбора данных является постоянным, это означает, что примерно каждые 15 минут приходят и маркируются новые данные, что требует постоянного обновления индекса.
Многие из моих запросов представляют собой ВЫБОР СЧЕТЧИКА ДАННЫХ между определенными ДАТАМИ и помечены конкретным ТЕГОМ для конкретного ЗАКАЗЧИКА (очень редко это касается нескольких клиентов).
Вот ситуация, которую вы можете себе представить с таким объемом данных, с которым я столкнулся с проблемой в плане организации и индексации данных. Опять же, это очень минималистичная и упрощенная версия моей структуры. У меня вопрос, так лучше:
Я запускаю все это на реплицированном выделенном сервере MySQL 5.0 (четырехъядерный, 8 ГБ оперативной памяти). Я использую только InnoDB, у меня также есть еще один сервер, на котором работает Sphinx. Так что, зная все это, мне не терпится услышать ваше мнение по этому поводу.
Спасибо.
редактировать
Благодаря вашим ответам я понимаю, насколько безумны эти цифры. Итак, вот обновленное более реалистичное использование таблиц (основанное на фактическом сервере, который представляет собой просто базовую стойку).
Спасибо.
Мои 2 цента, основанные на моем многолетнем опыте использования MySQL, заключаются в том, что ваш последний вариант звучит более логично и реалистично.
Использование одного Data и одного data_tag для каждого клиента дает более простую общую управляемость, чем ваша текущая схема. Кодирование для вашего второго варианта также будет проще.
Вы можете спросить у многих других экспертов по MySQL; ваш второй вариант - лучший.
Я могу уточнить детали, если хотите, это простой ответ на упрощенный вопрос к большой проблеме. это идет в обе стороны
Хм, по моему опыту - вы уверены, что MySQL даже лучшая база данных для этого? Пробовали смотреть на Oracle или SQL Server (хотя кластеризация Oracle может иметь здесь преимущество)?
Если вы думаете, что стоимость лицензирования вас убьет, позвольте мне просто сказать, что вы еще не представляете, какое оборудование вам понадобится для его запуска. Как только вы получите первые предложения по SAN, которые вам нужны, вы, вероятно, будете смеяться над ценой на соответствующее программное обеспечение.
Просто идея.
Становится безумнее.
Для эффективной обработки используется HIGH END SAN. Мы не говорим здесь о «10 дисках», мы говорим о high-end SAN с, возможно, 400 восходящими дисками для обработки всех этих данных - не забывайте, что пока у нас действительно нет НИКАКИХ индексов.
Я запускаю все это на реплицированном выделенном сервере MySQL 5.0 (четырехъядерный, 8 ГБ оперативной памяти).
ПРИЯТНАЯ попытка. Это хорошо для чего? Извините, что спрашиваю, но 8 ГБ ОЗУ действительно не поможет (не впечатлен здесь), выберите машину на 256 ГБ ... Для чего, вероятно, потребуется AMD и один из очень дорогих Opteron 8000. Но вам понадобится ОЗУ.
В любом случае, это будет (я сомневаюсь, что вы правильно представили факты) одной из крупнейших инсталляций баз данных в мире.
Вам ОБЯЗАТЕЛЬНО нужно что-то, что может с этим справиться - кластеризация Oracle или SQL Server может ускорить это, если вам действительно это нужно. Это imho ПУТЬ выше того, что бесплатные базы данных могут даже думать об обработке. В самом деле.
И вам нужны надлежащие процедуры резервного копирования (которых нет в MySQL). Вы также можете ПОНРАВИТЬСЯ Сжатие страниц данных SQL Serve 2008, которое МОЖЕТ уменьшить размер ваших данных на диске примерно на 50%. Не только для экономии затрат на диск, но и потому, что это означает меньшее количество операций ввода-вывода, что напрямую приводит к повышению производительности (поскольку вы не можете кэшировать таблицу в памяти).
Как бы я ни ненавидел это говорить, вы также можете рассмотреть возможность использования IBM DB2 на хорошем мэйнфрейме - и я не имею в виду запуск на нем виртуальную машину Linux. Благодаря аппаратной архитектуре VMS значительно превосходит работу с крупномасштабными базами данных. Не спрашивайте о цене;)
Сложно сказать, не зная много о вашем приложении, кроме того, что вы здесь разместили. Ваша модель данных довольно упрощена, и это в ваших интересах, поскольку вы ожидаете буквально миллиарды строк. Я бы не стал создавать более 5 КБ таблиц, так как вы, вероятно, столкнетесь с проблемами файлового дескриптора и ограничениями кеширования в будущем, если попробуете это.
Конечно, вы, вероятно, можете их отменить / настроить, но это все еще не оптимальная конфигурация.
Вы также создаете индексы для неключевых данных? Эти столбцы имени, например? Это может снизить производительность записи, так что будет выполнено резервное копирование 15-минутных пакетных заданий.
Честно говоря, если бы это было мое приложение, я бы рассмотрел два возможных решения:
Используйте то, что у вас есть сейчас, и разделите клиентов между несколькими серверами MySQL, если производительность станет проблемой. Если у вас нет этих данных и эти клиенты не выстроились в очередь, это еще не проблема. Не тратьте слишком много времени на проектирование «а что, если». Придерживайтесь упрощенной схемы и познакомьте свою первую группу пользователей с первым сервером. Когда вы начнете загружаться, введите второй сервер и изолируйте этих новых пользователей в этой базе данных. Шардинг, так сказать. Подкрепите это мониторингом ресурсов и хорошими методами администрирования, чтобы вы знали, когда линия "на полную мощность" приближается.
Что-нибудь вроде Cassandra или MongoDB будет работать? Я недостаточно знаю о ваших запросах, чтобы предложить это или исключить. MongoDB может быть вариантом. Стоит проверить.
Короче, я думаю, позвольте MySQL делать то, что у него хорошо получается, просто запускайте их больше. Или, если возможно, посмотрите что-нибудь вроде Mongo.
