Как следует организовать базу и поиск по 1 000 000 000 000 (триллиону) записей на 100ТБ?

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

В базу идут хэши, пока не знаю точной длины, думаю 32-64 символа utf-8.
С одного изображение будет примерно 5000 хэшей. Поскольку изображений будет очень много (ну реально очень много, как по мне) 720 000 000 (720 миллионов), то придется осуществлять поиск по более чем 1 триллиону записей, которые в свою очередь будут занимать примерно 100ТБ.
Как можно спроектировать структуру, что бы она была расширяема и вообще работала в таких условиях?
По идее поиск по хэшам должен быть за O(1), потащит ли MySQL?
В какую сторону копать? Спасибо!
  • Вопрос задан
  • 4933 просмотра
Решения вопроса 2
opium
@opium
Просто люблю качественно работать
Не потащит
Нужны эластиксерчи или касандры или МАП редьюс решения.
Ответ написан
Пригласить эксперта
Ответы на вопрос 11
Largo1
@Largo1
Айтишник далёкого плана
хм, странно всё это.. обычно кто создаёт подобную базу - уже знает что делать.. работайте с Oracle
Ответ написан
MaxDukov
@MaxDukov
впишусь в проект как DevOps.
столько не потянет и оракл. смотрите на хадуп
Ответ написан
sim3x
@sim3x
ФС тоже БД

PC-1 for routing
возвращает адреса машин, на которых лежат хеши и картинки по, 
например, первым 4 байтам хеша

PC-1 for hashes
|-/file_with_hash_of_region: content hash of image
|-....

PC-n for hashes
|-/file_with_hash_of_region: content hash of image
|-....

PC-1 for images
|-/image_file_with_hash_as_name
|-....

PC-n for images
|-/image_file_with_hash_as_name
|-....
Ответ написан
Dimchansky
@Dimchansky
Вряд ли что-то будет быстрее кластера из Aerospike с SSD дисками
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Каждый hash делайте первичным ключом и затем смотрите тут:
https://dev.mysql.com/doc/refman/5.5/en/innodb-ind...

UPD: я бы добавил, что для обучения и эталонирования образа (на основе множества подобных из БД), нужно удалять из дальнейшей выборки (однократным проходом по всей базе) промежуточные "близкие" "похожие" экземпляры, оставляя определённый процент допуска по параметрам. Таким образом, она не будет расти от "копий" подобных экземпляров.
Ответ написан
@beduin01
Попробуйте ArangoDB
API очень простое и скорострельность на высоте. Но это в том случае если с NoSQL хотите решением попробовать
Ответ написан
voidnugget
@voidnugget
Программист-прагматик
Я бы даже лучше уехал в сторону scylladb - более толковая штука чем Cassandra / Hbase.
Ответ написан
@gro
Столько ответов, притом, что никто даже не уточнил, что автор подразумевает под поиском по хэшам.
Просто по одному хэшу возвращать айдишник фотки?
Ответ написан
AterCattus
@AterCattus
Люблю быстрый backend
Если нужно получать идентификаторы картинок, чьи хеши встречаются наиболее часто в запрошенной выборке, то тут нужно строить не просто key-value, а более оптимальные индексы...
Ответ написан
@pansa
Лично меня еще смутили такме моменты:
1) а что это за хэши такие странные - в символах UTF8? Вкурсе, что _1 символ_ в этой кодировке может занять от 1 до 6 байт, что на таком кол-ве записей ведет к огромному разбросу. Если у вас хэш из ASCII, то тогда зачем притянули сюда UTF8?
2) 32-64 символа -- так 32 или 64? На вашем кол-ве это разница +- 50Тб . Это довольно серьезные объемы.
3) Как вы посчитали 100Тб? Вы учли место под индекс?

Идеи по проблеме:
1) тащить сюда реляционку не стоит, ибо...
2) очевидно, что это всё надо запускать не на одной машине, на глаз - минимум 2, не считая бэкапа (он нужен?) либо реплик => шардинг => kv-хранилища подойдут лучше (если мы правильно поняли, что вы хотите)
3) ничего не сказано про кол-во запросов - вставки/чтения. Но я бы подумал над размещением перед этим хранилищем предварительной проверке по фильтру Блума, чтобы лишний раз не стукаться в хранилище. Но это надо знать характер данных и запросов.
Ответ написан
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы
24 мая 2019, в 23:37
100000 руб./за проект
24 мая 2019, в 21:53
500 руб./в час
24 мая 2019, в 21:36
500 руб./за проект