Привет всем. Имеется около 50-60 числовых параметров, штук 4 строковых и около десятка bool. Как оптимальнее сделать таблицу в БД, чтобы потом не было проблем с реализацией фильтрации?
Спасибо)
Akina, около пары сотен записей максимум. Нагруженность проекта не большая и вряд ли будет большой. Про распределение по типам не скажу, тыкните, где почитать)
Если у вас есть сет поисковых атрибутов, по которым будет поиск то можете построить по ним композитный индекс.
На этом пожалуй все.
Практически невозможно спроектировать таблицу которая-бы быстро отбивала любые типы поисковых запросов. Более того. Если вы щас построите кучу ненужных индексов - сложно будет в будущем проводить сравнительный анализ "как было" и "как стало". Поэтому не делайте вообще ничего. Пускай будет простая таблица без индексов. А когда будет конкретный запрос который работает плохо - вот тогда будете делать тюнинг.
Это подтверждает Дональд Кнут который говорит что оптимизация раньше времени - это корень всех зол.
yarovikov, да. В области BigData, где я работаю - индексы вообще не исопользуются. Там просто partitioning, Z-Order и различные хитрости для сжатия вертикальных колонок. Просто запросы обычно идут массовые. Аналитика и маш-обучение. А для них индексы особо не нужны.
yarovikov, для начала, пересмотреть подход. Потому что таблица с 50-60 колонок - это, скорее всего, ерунда какая-то. Надо посмотреть, что в них, и решить, как лучше организовать. Например, можно класть некоторые "неосновные" параметры в отдельную таблицу с key и value. Типа такого:
Запись для id=1 name=foo description=bar lorem=ipsum vladimir=putin класть в две таблицы:
Это заодно позволит при необходимости расширять число полей. Неудобство - для получения информации нужно будет делать два запроса или join с постобработкой.
Можно также хранить дополнительные параметры в виде текстового поля, где, например, json, но тогда по ним нельзя будет фильтровать (но в реальных задачах могут быть примеры данных, где фильтровать по всем не нужно).
Можно использовать key-value фичи некоторых баз (поля типа json, hstore итд), тогда по ним можно даже фильтровать и в принципе можно даже строить индексы по конкретным key-value парам.
Наконец, если это данные, например, каких-то регулярных измерений, то возможно имеет смысл сразу подумать о специализированных базах или настройках к имеющимся базам для временных рядов.
Выбор решения требует слишком глубокого погружения в задачу: структура данных, объём, способы работы с ними...
shurshur, понял, спасибо. Тогда последний вопросик - каким образом обычно делают хранение массива, чтобы по его значениям таки можно было фильтровать без головной боли?
yarovikov, обычных способов много, в том числе таких, которые сейчас уже в целом не принято делать (например hstore в Postgres считается устаревшим и рекомендуется использовать json). Более того, бывает часто так, что люди выбирают не самое удачное решение, а потом весь жизненный цикл проекта с ним мучаются.
Приведу пример из своей практики. Есть вот такой сайт: osm.sbin.ru/esr
Там есть супертаблица stations, в которой много колонок типа name_tr4, name_gdevagon, name_yarasp. Позже для новых данных я начал применять другой подход: каждый источник загружается в свою таблицу, а к общей таблице они подключаются через LEFT JOIN по ЕСР-коду. Это оказалось во многих отношениях лучше, например, гораздо удобнее обновлять данные источников. Но запросы стали более сложными. И до кучи далеко не по всем данным это переделано, тем более исходные источники ряда данных не сохранились и их обновить уже нельзя, только синтезировать разбором данных супертаблицы, что не особо имеет смысл теперь.
mayton2019, "сжатие вертикальных колонок" - это вы похоже про колоночные СУБД, а это вообще к вопросу не относится. И индексы в классическом понимании там не используются, потому что принципы другие, т.к. задачи другие.
yarovikov, никак не сделаете оптимально, потому что данные в базе нужно располагать не так, чтобы они красиво лежали, а чтобы соответствовали тем селектам, которые вы будете направлять в базу. Если знаете, что и как будете запрашивать, то сможете спроектировать базу. Если не знаете, то это уже преждевременная оптимизация, которая ненужна.
Тем не менее, очень сомневаюсь, что вам понадобится выборка по 50-60 числовым полям. И тут, предложенный вариант с key-value или даже json выглядет более вероятными. Тем более с вашим объемом данных, будет не проблема поменять структуру БД при изменении требований.
И, кстати, строковые это какие? Какая у них максимальная длина?
shurshur, а что именно стало лучше и удобнее? Я так понимаю, для выборок вам нужны данные из всех таблиц, следовательно здесь стало хуже. Ускорилась вставка из-за меньшего объема данных, более коротких блокировках и блокировки идут на разные таблицы, так?
На сайте таблица не выглядит большой, о каких объемах идет речь?
Vitsliputsli, вставка там бывает очень редко и её скорость вообще не волнует, основная задача там - это вывести данные, а для этого единственное узкое место не в самих станциях, а в stations_of_lines, которые сделаны хреновенько, но переписывать лениво (можно в любой регион ткнуть и увидеть, что таблица грузится не супер быстро, но вполне приемлемо).
к сожалению, есть определенные ограничения на текущем проекте
Причем здесь Ваш проект? В вопросе лишь следующие требования:
- Имеется около 50-60 числовых параметров, штук 4 строковых и около десятка bool.
- чтобы потом не было проблем с реализацией фильтрации.
