Хранение большого количества данных (1 Viewer)

[zbkm]

Как хранить данные, в какой бд.

1) Текстовые строки, 40гб+ (миллиард строк).
Каждая строка уникальна, и поделена на подстроки (которые будут храниться в отдельных ячейках). Подстроки не уникальны. Нужно будет производить выборку по подстрокам и возвращать соответствующие им строки.
2) Картинки 32х32, несколько сотен миллионов + текстовые строки. Сами картинки не нужны (хранить их хэши? какие?). Только проверять их наличие в базе, и если есть возвращать связанные строки, следовательно строк у одной картинки может быть несколько. Картинки и строки уникальны (то есть на моменте парсинга планирую откинуть все дублирующиеся значения).

Конечно, думал, всё засунуть в mysql, но вдруг есть варианты лучше?

 

[MaHarder]

по мне, так Postgres. Он норм работает с такими данными.
я молчу, что данные сконвертировал с ms server 2000 размером в 60 гигов

 

[SaNcHeS]

Больше будет чтения или записей?
Под такие задачи я бы посоветовал уйти в no sql
elasticsearch или redis подойдут

 

[zbkm]

Больше будет чтения или записей?

1 - преобладает чтение
2 - запись

 

[SaNcHeS]

elasticsearch

 

[zbkm]

Я, возможно, неправильно выразился. В случае с строками преобладает чтение, а с картинками запись.
Но сейчас вопрос немного в другом. А как тогда лучше хранить картинки? Хранение в файлах похоже не лучший вариант, так как поиск будет производиться именно по ним. И тут либо в виде бинарных данных (но как это может сказаться на поиске?), либо в виде хэшей (но как-же коллизии)?