93 млн. - сама по себе
смешная нагрузка для современных СУБД на современных компьютерах.
Выбор СУБД зависит от того - а
что именно вы собираетесь с этой базой данных делать.- в вопросе это не указано.
Ну например, если ваша цель быстро искать в это БД товары, а ваши 30 колонок - это фильтры, то отлично подходит СУБД для именно что полнотекстового поиска (пусть вас не смущает название, для фасеточного поиска она тоже подходит отлично). Это, к примеру:
- если вы ориентированы на скорость SphinxSearch
- если вам нужен кластер, то это ElasticSearch
- если вам нужны традиционные инструменты типа SQL, - то это PostgreSQL, MySQL.
Если же задача другая - то идеальным выбором может быть и другая СУБД.
Нужны детали.
Думаю, дело в том, что вы увидели эти 90 млн. и решили, что нужно какое-то специфичное решение и не стали даже уточнять детали - а на деле, ничего такого в этих 90 млн. нет. А вот детали задачи - важны.
Рассмотрим задачу быстрой перезаписи - вы имели ввиду все 90 млн. перезаписывать целиком? Не частично. А вот это будет действительно проблемой. Мало какая из СУБД способна на быстрые изменения такого объема.
Ну и третий раз повангую - максимально быстрый доступ к данным - это если данные размещены в оперативной памяти. Один из наиболее развитых инструментов, с размещение в оперативной памяти и с функционалом СУБД - Tarantool. Быстрее, чем in-memory DB, к которым относится Tarantool - и вариантов нет.
Но понадобится соответствующее количество оперативки.
Если оперативки мало, то можно глянуть Aerospike. Это "почти in-memory DB". Но объемы данных могут быть огромны, при небольших запросах к оперативке. От оперативки требуется только целиком вмещать индексы, а не сами данные.
Короче, ванговать мне надоело.
У вас нет постановки задачи - ответить вам посему и нечего конкретного невозможно.
