30 миллионов записей в день, SQL Server не справляется, нужен другой тип базы данных?

Question

Некоторое время назад я подумал о создании новой системы статистики для нашего многомиллионного веб-сайта, чтобы регистрировать и сообщать пользовательские действия для наших клиентов.

Структура базы данных довольно проста, содержит одну таблицу с ForeignId (200 000 различных идентификаторов), поле datetime, actionId (30 различных идентификаторов) и еще два поля, содержащие некоторую метаинформацию (только smallints). Нет ограничений для других таблиц. Кроме того, у нас есть два индекса, каждый из которых содержит 4 поля, которые нельзя отбрасывать, поскольку пользователи получают тайм-ауты, когда у нас есть меньшие индексы. ForeignId является наиболее важным полем, так как каждый запрос содержит это поле.

Мы решили использовать SQL-сервер, но после внедрения реляционная база данных не выглядит идеально подходящей, так как мы не можем вставлять 30 миллионов записей в день (это только вставка, мы не делаем никаких обновлений), когда также выполняем много случайных чтений в базе данных; потому что индексы не могут быть обновлены достаточно быстро. Ergo: у нас огромная проблема :-) Мы временно решили проблему, но

реляционная база данных не подходит для этой проблемы!

Будет ли база данных вроде BigTable лучшим выбором и почему? Или есть другие, лучшие варианты при решении подобных проблем?

NB. На данный момент мы используем одну 8-ядерную систему Xeon с 4 ГБ памяти и Win 2003 32-разрядной. RAID10 SCSI, насколько я знаю. Размер индекса примерно в 1,5 раза больше размера таблицы.

Answer 1

Вы говорите, что ваша система способна вставлять 3000 записей в секунду без индексов, но только около 100 с двумя дополнительными некластеризованными индексами. Если 3 к / с - максимальная пропускная способность, которую разрешает ваш ввод / вывод, то добавление двух индексов теоретически должно снизить пропускную способность примерно на 1000-1500 / с. Вместо этого вы видите ухудшение в 10 раз хуже. Правильное решение и ответ - «Это зависит», и необходимо провести серьезную диагностику и выявить узкие места. Имея это в виду, если бы я рискнул предположить, я бы дал два возможных виновника:

A. Дополнительные некластеризованные индексы распределяют записи грязных страниц в большее количество областей выделения. Решение состоит в том, чтобы поместить кластеризованный индекс и каждый некластеризованный индекс в свою собственную файловую группу и разместить три файловые группы в каждой на отдельных логических модулях RAID.

B. Низкая селективность некластеризованных индексов создает высокую конкуренцию между операциями чтения и записи (конфликты ключей, а также % lockres% конфликтов ), что приводит к длительному времени ожидания блокировки как для вставок, так и для выборок. Возможные решения - использование SNAPSHOT с режимом фиксации моментального снимка для чтения , но я должен предупредить об опасности добавления lot IO в хранилище версий (т.е. в tempdb) в системе, которая уже может находиться под высоким напряжением ввода-вывода. Второе решение - использовать снимки базы данных для создания отчетов, они вызывают более низкую нагрузку ввода-вывода и их можно лучше контролировать (хранилище версий tempdb не используется), но отчеты больше не передаются в режиме реального времени.

Я склонен полагать, что B) является вероятной причиной, но я должен еще раз подчеркнуть необходимость надлежащего расследования и надлежащего анализа случаев заболевания.

«RAID10» не очень точное описание.

• Сколько шпинделей в части RAID 0? Они с короткой полоской?
• Сколько LUNs?
• Где находится журнал базы данных?
• Где находится база данных?
• Сколько разделов?
• Где находится база данных tempdb?

Что касается вопроса, подходят ли реляционные базы данных для чего-то подобного, да, абсолютно. Есть еще много факторов, которые необходимо учитывать: возможность восстановления, доступность, экосистема набора инструментов, ноу-хау, простота разработки, простота развертывания, простота управления и т. Д. И т. Д. Реляционные базы данных могут легко справиться с вашей рабочей нагрузкой, им просто нужно правильно настроить. 30 миллионов вставок в день, 350 в секунду, это небольшое изменение для сервера базы данных. Но 32-битная 4 Гб оперативной памяти вряд ли сервер базы данных, независимо от количества процессоров.

Answer 2

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

Рассматривали ли вы что-то вроде индексированных представлений в SQL Server? Это хороший способ удалить индексирование из основной таблицы и переместить его в материализованное представление.

Answer 3

Можно попробовать сделать таблицу секционированной . Таким образом, обновления индекса будут влиять на меньшие наборы строк. Вероятно, ежедневного разбиения будет достаточно. Если нет, попробуйте разделить по часам!

Answer 4

Репликация базы данных для отчетов кажется лучшим маршрутом, учитывая интенсивный трафик. Тем не менее, пара вещей, чтобы попробовать в первую очередь ...

Идти с одним индексом, а не двумя индексами. Кластерный индекс, вероятно, будет лучшим выбором, чем некластеризованный. Меньше, более широкие индексы обычно работают лучше, чем более узкие индексы. И, как вы говорите, именно индексирование убивает ваше приложение.

Вы не говорите, что используете для идентификаторов, но если вы используете GUID, возможно, вы захотите изменить свои ключи на bigints. Поскольку идентификаторы GUID являются случайными, они ложатся тяжелым бременем на индексы как при создании индексов, так и при их использовании. Использование столбца идентификаторов bigint сделает индекс работающим в хронологическом порядке, и если вы действительно заинтересованы в доступе в режиме реального времени для запросов к вашим недавним данным, ваш шаблон доступа гораздо лучше подходит для монотонно увеличивающихся ключей.

Answer 5

Вы не предоставляете достаточно информации; Я не уверен, почему вы говорите, что реляционная база данных выглядит плохо, за исключением того факта, что у вас сейчас проблемы с производительностью. На каком компьютере запущена СУБД? Учитывая, что у вас есть сторонние идентификаторы, кажется, что реляционная база данных точно , что здесь требуется. SQL Server должен обрабатывать 30 миллионов операций вставки в день, при условии, что он работает на достаточном количестве оборудования.

Answer 6

Вы не говорите, как управляются вставки. Они группируются или каждая статистика записывается отдельно? Потому что вставка тысячи строк в одну операцию, вероятно, будет более эффективной, чем вставка одной строки в тысячу отдельных операций. Вы все еще можете вставить достаточно часто, чтобы предлагать более или менее отчет в реальном времени;)

Answer 7

Не уверен насчет SQL-сервера, но в другой системе баз данных, которую я использовал давно, идеальным методом для этого типа операций было сохранение обновлений, а затем, как пакет, отключение индексов, добавление новых записей и затем повторная индексация. Мы делали это один раз за ночь. Я не уверен, что ваши потребности в отчетности подойдут для этого типа решения или даже если это можно будет сделать в MS SQL, но я думаю, что это возможно.

Answer 8

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

Однако мне интересно, ДОЛЖНЫ ли вы хранить все 30-миллиметровые записи? Не лучше ли хранить некоторые предварительно агрегированные данные?