Какую базу данных использовать для 93 млн строк (товары)?

Есть 93 млн строк (товары) 32 колонки
Какую базу данных использовать?
Что можно еще использовать в архитектуре для быстрого вывода, записи и перезаписи данных?

Возможно ваши советы.
Заранее благодарен...
  • Вопрос задан
  • 2685 просмотров
Пригласить эксперта
Ответы на вопрос 7
@awesomer
93 млн. - сама по себе смешная нагрузка для современных СУБД на современных компьютерах.
Выбор СУБД зависит от того - а что именно вы собираетесь с этой базой данных делать.- в вопросе это не указано.

Ну например, если ваша цель быстро искать в это БД товары, а ваши 30 колонок - это фильтры, то отлично подходит СУБД для именно что полнотекстового поиска (пусть вас не смущает название, для фасеточного поиска она тоже подходит отлично). Это, к примеру:

  • если вы ориентированы на скорость SphinxSearch
  • если вам нужен кластер, то это ElasticSearch
  • если вам нужны традиционные инструменты типа SQL, - то это PostgreSQL, MySQL.


Если же задача другая - то идеальным выбором может быть и другая СУБД.
Нужны детали.

Думаю, дело в том, что вы увидели эти 90 млн. и решили, что нужно какое-то специфичное решение и не стали даже уточнять детали - а на деле, ничего такого в этих 90 млн. нет. А вот детали задачи - важны.

Рассмотрим задачу быстрой перезаписи - вы имели ввиду все 90 млн. перезаписывать целиком? Не частично. А вот это будет действительно проблемой. Мало какая из СУБД способна на быстрые изменения такого объема.

Ну и третий раз повангую - максимально быстрый доступ к данным - это если данные размещены в оперативной памяти. Один из наиболее развитых инструментов, с размещение в оперативной памяти и с функционалом СУБД - Tarantool. Быстрее, чем in-memory DB, к которым относится Tarantool - и вариантов нет.

Но понадобится соответствующее количество оперативки.

Если оперативки мало, то можно глянуть Aerospike. Это "почти in-memory DB". Но объемы данных могут быть огромны, при небольших запросах к оперативке. От оперативки требуется только целиком вмещать индексы, а не сами данные.

Короче, ванговать мне надоело.

У вас нет постановки задачи - ответить вам посему и нечего конкретного невозможно.
Ответ написан
Комментировать
@res2001
Developer, ex-admin
Из бесплатных PostgreSQL, оптимизируйте индексацию, систему хранения СУБД и дисковую подсистему ну и памяти в сервер добавьте, если нужно.
Вообще вопрос абстрактный.
Если вас не устраивает существующий вариант, то нужно найти что именно привело к этому - возможно какая-то конкретная операция (или несколько) заставляет тормозить сервер, нужно их найти и разбираться с ними.
Если просто заменить СУБД, оставив приложение в том же виде, то на новой СУБД вы скорее всего словите те же проблемы, возможно не сразу, а через какое-то время.
Ответ написан
Комментировать
AndyKorg
@AndyKorg
Кнопконажиматель и припоерасплавлятель
Слишком расплывчатое ТЗ. 93 млн в одной таблице? Колонки в таблице длинной 20 байт? Одна таблица в БД?
Вообщем наймите архитектора, что бы потом не мучится с низким быстродействием, внезапными блокировками и прочими прелестями ошибок в архитектуре.
Ответ написан
@vanyamba-electronics
На мой взгляд, достаточно очевидно, что какую базу ни возьми, в одну таблицу все эти товары записывать бессмысленно - все операции с такой таблицей будут занимать продолжительное время.
Ответ написан
Да какую угодно.
Можно вообще обойтись без БД.
Например каким-нибудь hadoop или kafka.
<:o)
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Свой тип товара - своя таблица и приведение к ДНФ3. БД - любая.
Ответ написан
Комментировать
@asd111
Если количество колонок постоянное и таблица денормализована, то postgresql.
Если количество колонок меняется и таблица денормализована, то mongodb.
Вместо mongo можно использовать postgres jsonb, но синтаксис запросов там довольно специфичный. Postgres jsonb работает быстро как mongo.
Если таблица нормализована, то будет тормозить на слабом железе.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы