Как организовать в Linux с 10 000 000 000 (миллиардами) inodes, быстрый доступ к ним и их обработку (Линукс замена бд)?

Нужен поиск и вставка миллиардов записей. Пробовал elasticsearch - после 50 000 000 записей тяжко идет вставка. Думал еще попробовать Cassandra. Но задумался, зачем для элементарных действий брать такие машины - огромные и неповоротливые. Да, в них все отлично продумано и классно масштабируемо. Проблема в этом всем - универсальность, как и во всех массовых продуктах. Как обычно, приходится педалить

Есть данные вида:
Хэш          Инфо
aDs3g9     2:1,2,4;11:1  (где 2, 11 - ключи, а 1,2,4 и 1 - поля к этим ключам, остальное - разделители)
3trhn        2:9,7;3:3,4

На данный момент длина хэша 1-6 символов взятых из (макс инт 32) - дает 4 000 000 000 вариаций
Попробуем организовать все в виде ФС на Linux.

Задача1: быстрая вставка, наподобие upsert в ES
Зная умные слова типа шардирование и партицирование на ум продит следующее:
1) Берем хэш aDs3g9, и создаем папки с каждыми 2мя символами и бросаем в последнюю файл нашего хэша, выходит так - aD/s3/g9/aDs3g9
Приходит запрос - положить в aDs3g9 "2:1,2" - тут появляется вопрос : "Стоит ли создать все возможные папки до вставок или создавать их по ходу вставок?". Допустим папки у нас есть, дальше вставляем ключ 2 и данные 1,2.
Приходит следующий запрос - положить в aDs3g9 "2:4" - видим в папках уже есть файл, считываем его, докидываем в нужное место "4" и получаем "2:1,2,4"
Далее - положить в aDs3g9 "11:1" - получаем "2:1,2,4;11:1"
Что мы имеем - жертвуя время на добавления информации в файл без дублей при индексировании мы экономим место и время при выборке. Если не хотим жертвовать временем при вставке, то выйдет так "2:1,2;2:4;11:1"

Задача2: быстрая выборка всех ключей и значений, пусть даже с дублями ключей
Приходит - дай мне все с aDs3g9, 3trhn (тут может прийти список до 1000 хэшей) - возвращаем "2:1,2,4;11:1 2:9,7;3:3,4"
Вопрос в параллелизме - linux может параллельно доставать файлы? 1000 хэшей разбиваем на 10 потоков и каждый из них работает пока не достанет все данные из своих файлов.

Какой тип ФС выбрать чтобы можно было держать до 10 миллиардов inodes и какой обьем памяти для этого может понадобиться? Понятно, что можно разбить на сервера, каждый из которых будет хранить свою область хэшей, но вот допустим это все будет на 1 машине.

Разных символов в хэше = 26 + 26 + 10 = 62 (26 маленьких, 26 больших и 10 цифр)
Напомню, то хэш берется с макс инт 32, поэтому папки дают 4 и файлы дают 4 миллиарда
Итого 8 000 000 000 файлов на данный момент.

Какие мысли по такому решению? И на чем лучше писать высио это для максимальной скорости c/c++ ?
  • Вопрос задан
  • 1291 просмотр
Решения вопроса 1
@lega
Классическая фс для этого не подходит, если у вас размер данных на "хеш" небольшой, например до 100 байт, то просто сделайте большой файл на 400гб и пишите данные по индексу, при этом хеш не нужен. С нормальным ssd можно будет писать до 1М записей в сек. обычным скриптом. При этом 75% места будут "простаивать". Если хотите сэкономить места, тогда нужно использовать индекс, например заюзать leveldb или т.п.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
begemot_sun
@begemot_sun
Программист в душе.
Вы также должны учесть, что информация на жестком хранится минимальными порциями, например по 16 кб или по 4кб (не помню точно).

Получается вы будете иметь значительных оверхед на жестком.
Ответ написан
Ваш ответ на вопрос

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

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