MS sql. Тысяча таблиц или одна большая?

Question

[paz]

Добрый день, уважаемые знатоки MS SQL

Имеется база куда с большой частотой пишутся данные по 2-3 тысячам сущностей. Пишется все в несколько таблиц. Объем базы больше 1тб, рост около 50-60 гб/ месяц.

С ростом базы начались проблемы по скорости при вставке. Также, т.к. база должна быть онлайн 24х7 возникали проблемы при необходимости переиндексации или диагностики базы (необходим был монопольный доступ)

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

По использованию базы: пишется постоянно практически в каждую сущность с интенсивностью раз в 1-5 секунд. Читается по разному, в зависимости от активности пользователей, в основном нечасто, но выборка должна быть быстрой, чтобы получить строк 20-30 тыщ за пару секунд. Хранилище на ssd.

Answer 1

[nApoBo3]

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

Comments

[paz]

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

[paz]

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

[nApoBo3]

paz: Если в таблице один индекс по времени, и нет ограничений, то вставка данных не должна значительно замедляется с ростом их кол-ва. В зависимости от структуры данных возможно можно отказаться от индекса по времени, заменив его rcid метками. В данном случае проще разделить данные не по сущностям, а по времени.

[paz]

nApoBo3: что такое rcid метки? гугль не знает :) Тогда еще вопрос. У меня в базе около 5 млрд записей. Появляется задача часть данных вынести на быстрые носители, критерий отбора по сущностям и по времени. Если одна таблица то как такое средствами mssql сделать? Вообще любые манипуляции с большими таблицами это гемор. сейчас при выполнении DBCC CHECKDB нам надо останавливать все и не факт что это перелопатится за ночь :)

[nApoBo3]

paz: автоинкриментный первичный ключ. Если выборка у нас не произвольная, а ступенчатая, то можно начало каждой ступеньки заносить во внешнюю таблицу, и делать выбоку по данному значению, такое хитрое партицирование получается. Если бить надо по сущностям, то несколько таблиц. Возможно имеет смысл, выделить отдельный сервер для выборок и реплицировать его.

[nApoBo3]

paz: возможно вообще имеет смысл разделить базу на несколько, не зная структуру данных и задачи сказать сложно.

Answer 2

[lega]

Разными таблицами должно быть лучше, ещё можете попробовать партицирование и сжатие.

получить строк 20-30 тыщ за пару секунд

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

Answer 3

[sim3x]

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

неправильная архитектура - не нужно писать raw логи в бд
для каждого датчика своя таблица

как бекапить

никак - поднимай репликацию

как выделить часть данных, которые чаще всего используются и должны работать быстрее, чем архивные

определи период, через, который данные отправляются в архив
разбей их на периоды (за месяц или за неделю)
оставь в виде статических файлов

И еще
У тебя не бигдата - у тебя неправильная архитектура

Comments

[paz]

неправильная архитектура - не нужно писать raw логи в бд

а я и не пишу RAW, пакеты парсятся и пишутся в бд

для каждого датчика своя таблица

датчик или прибор? У нас в системе есть несколько тысяч приборов, которые шлют данные. в каждом приборе несколько датчиков.
делать таблицу на отдельный прибор или на отдельный датчик?

[sim3x]

paz:
>я и не пишу RAW, пакеты парсятся
хорошо, но нужно пойти дальше

нужно нормализировать схему хранениния

если есть несколько приборов с одинаковыми датчиками, но датчики могут стоять только на данных приборах, то делаем таблицу для данных приборов с полями в виде их датчиков

если в ножестве приборов есть одинаковые датчики и часто нужно агрегировать данные по датчикам, а не по приборам, то делаем таблицу с приборами и таблицу с датчиками и привязываем датчики к приборам

подробнее см 3-я формальная форма, Форма Бойса-Кодда