Какую key-value БД использовать с данными в 10 млрд строк записей?

Посмотри как тут делают https://dev.mysql.com/doc/refman/8.0/en/create-tab...

и попробуй повторить эксперимент для MyISAM, InnoDB

create table(....) ENGINE=MyISAM;

create table(....) ENGINE=InnoDB;

потом построй индекс для 2 вариантов.

10 лярдов грузить не надо. Загрузи только минималку где воспроизводится дефект.

Какую key-value БД использовать с данными в 10 млрд строк записей?

gamoyo5524, не интересует. Я здесь просто время провожу. Заработок и так есть.

Какую key-value БД использовать с данными в 10 млрд строк записей?

gamoyo5524, ну вот я тут. Вот и связывайся. У меня нет секретов от хабра.

Какую key-value БД использовать с данными в 10 млрд строк записей?

Никита Савченко,

Но если нужна простота и быстрота - MongoDB.

ммм... нет. Монго здесь скорее всего не подходит.

Какую key-value БД использовать с данными в 10 млрд строк записей?

Да. По поводу этой ошибки.

ERROR 1034 (HY000): Index for table 'TABLE_NAME' is corrupt; try to repair it

Я к сожалению не знаю что это. Но думаю что в форуме сидят другие MySQL-щики
которые уже с этим сталкивались. Как вариант - ты превысил лимиты на что-то.
И возможно надо резко поменять конфигурацию. Engine поменять например.

Какую key-value БД использовать с данными в 10 млрд строк записей?

- возможность одному значению задавать 5 ключей и более (некоторые ключи могут совпадать)

1) Непонятно что может совпадать. Всмысле работает как compressed index Oracle?

CREATE INDEX t1_idx ON t1(key1, key1,key3) COMPRESS 5;

Если ключи key1 будут повторяться в серии строк то oracle не будет выделять под них дополнительное место. Это имелось в виду?

2) Непонятно почему их стало 3. Ведь сначала речь шла о 5 ключах.

3)

На данный момент данные построчно записанны в .txt которые я переконвертировал в .sql

Не надо конвертить в SQL. Лучше конвертить в CSV. У всех dbms есть коробочные средства загрузки
comma-separated и работает быстрее потому что нет лишней фазы синтаксической SQL трансляции.

4)

если создать пустую структуру и задать столбцам сразу индекс быстрый импорт превращается в очень медленный, будто скорость -x100, и я подумал без индексов загрузить сразу 5 млрд записей а дальше задать индексы но не тут та было спустя ~ 6 часов обработки ошибка "ERROR 1034 (HY000): Index for table 'TABLE_NAME' is corrupt; try to repair it"

Раз уж ты начал мучать MySQL то его надо домучать до конца. Значит стратегия должна быть такая.
Создается пустая таблица без индексов и констренйтов. В нее загружается все. Потом индекс включается
через create index...

Как разогнать? Надо понять степень параллелизма дисковой системы. Если у тебя таблица стоит на RAID 10 к примеру то можно создать семейство таблиц с одинаковой шапкой

table1
table2

И грузить скриптами паралелльно. Но надо внимательно мониторить. Если скорость загрузки стала хуже
- то вернуться обратно к однопоточной процедуре загрузки.

При параллелизме не надо их соединять. Пускай система так и работает. А роутинг запросов
ты будешь адресовать к нужной таблице по хешу.

Тоесть если hash(key1,key2,key3) == 0 по модулю 2 то пишешь в первую таблицу.
Если равен 1 по модулю два - то во вторую.

По такому-же принципу режешь CSV данные на два стрима. На прикладом уровне понятное дело.
Как ты это сделаешь (на Python или на Bash или на Ruby) я не знаю. Я здесь как мудрый филин
говорю ежам что надо вырастить колючки.

Тобишь я предполагаю что ты - разработчик системы и знаешь что такое хеширование в прикладном
коде и хеширование в MySQL. Но это - серебрянная пуля которая всегда помогала разогнать
медленные системы.

Этот-же принцип кстати работает и в DynamoDb, CosmosDb и прочее. Данные хешируются и потом
пишутся в хеш-блоки хранилища. Именно так Майкрософт и Амазон достигают гарантированной
пропускной способности. Сколько заплатил - столько и юнитов параллелизма получит. У них
даже термин свой был. Типа provisioned чего-то там...

Чем шифровать жесткий диск, чтобы открыть его на Android?

Данное заявление - обескураживает!

Шифрование файловой системы по типу encfs, cryfs и тому подобные не интересует. Нужно что-то вроде VeraCrypt.

Складывается впечатление что автор - человек опытный. И уже попробовал что-то. И что-то не подошло. То типу лицензии. Или по классу инфо-защиты. Нам хотелось-бы знать почему не подошло. В противном случае выглядит как - вот я арбузы не хочу, а хочу только дыни.

Для ясности ответа хотелось-бы понять что же на самом деле хочет автор.

Какую key-value БД использовать с данными в 10 млрд строк записей?

Никита Савченко,

Для большой БД это невыгодно. 10 млрд записей сожрут много ОЗУ.

Отвечая на вопрос я обычно привлекаю базовую арифметику. Если ключом является например
телефон (тех-средство) и значением например статус (активен-неактивен) - то мы можем
примерно прикинуть сколько нам надо памяти в сыром виде. И от этого дальше рассуждать.
Накинуть коэффициентик для накладных хеш-таблицы.

Но я подожду пока автор ответит на вопрос об общем объеме датасета.

Какую key-value БД использовать с данными в 10 млрд строк записей?

Никита Савченко, MySQL - это некий лейбл под которым работают различные engines. И чисто для прояснения
ситуации я-бы спросил об условиях бенчмарка.

Какую key-value БД использовать с данными в 10 млрд строк записей?

Я-бы начал торги с подсчета исходных данных. Сколько их не в ключах а в гигабайтах? Исходя из этого можно дальше прикидывать что это. Сервер или грид из серверов. Все архитектуры хорошие и годные.

Какие промпты побудят ChatGPT начать генерировать эмодзи, состоящие из небуквенных символов?

Никому не интересен "вечный" двигатель. Или телепортация материи на расстояние.
Вот эмодзи надо сгенерировать. Офигеть информационная задача 21 века!

Я ворчу конечно. Я ворчун такой. Убежден что "плоскоземельщики" и верователи
"макаронного монстра" тоже поставят себе задачу заставить GPT выдать себе ответ
которые ожидается.

Мне это напоминает парадоксы статистики. Людям не интересна истина. Им только
нужно по быстрому доказать свою гипотезу и прервав эксперимент срочно публиковать
сенсацию.

Spring batch или Spring Integration?

Складывание путей в базу - выглядит лишним. Если полезный эффект от джоба - это сохранение pojo - то сохраняй только pojo.

Данная задача может быть полностью решена на pure java. И я не вижу смысла затаскивать Spring Batch.
В крейнем случае если вы - техно-фетишисты и просто любите Спринг то - берите конешно. Но тогда
сам по себе вопрос Batch/Integration в топике выглядит хитро и лукаво. Это как пикапить девушку на улице и сразу
спрашивать ее что она любит кофе или мороженное. Все равно выбора ей не оставляете. Вроде как уже
согласна пойти с вами.

Требуется перебрать список и получить последовательности со значениями больше 0. Как?

Последняя девятка не закрывается нулем. И из-за этого не формирует последний под-список.
И хотя оно автору не надо под длину массива. Но это тоже краевой кейс которые не протестирован.

Вообще задание поставлено очень тухло. В таком виде например на leetcode/codewars нельзя задачи
ставить. Нужно рассматривать все варианты и расписывать corner cases.

Spring batch или Spring Integration?

Spring Integration тут не нужен. Он - ближе к обработке событий.

Вот эти два пункта

прочитать файл ( xml) - распарсить с доменную модель
3.Сохранить в базу данных

надо расписать поподробнее.

Насчет Spring Batch я не уверен. Он пока выглядит овер-проектированием.
После того как ты распишешь подробно что делают все stages этого джоба
тогда и можно обсудить применимость Spring Batch.

Spring batch или Spring Integration?

stas1212, какое у вас облако? AWS? Azure? GCP?

На сколько сложно утроиться джуном на позицию C++ dev?

stas1212, ушел от дел. Теперь я дата-инженер. И spring от меня далеко. Ты задавай вопросы как обычно. Через форму. А то щас модер все поудаляет.

На сколько сложно утроиться джуном на позицию C++ dev?

stas1212, ну здарова Стасян. Чо как. Как сам?

На сколько сложно утроиться джуном на позицию C++ dev?

stas1212, а хрен ево знает. Может я. А может и моя цифровая GPT-копия. Ты на скруле кем был?

На сколько сложно утроиться джуном на позицию C++ dev?

Эх лет 20 назад можно было спокойно писать на такие темы. Славное было время. udaff.com, bash.org, фишки, пикабушки. Щас кругом - наблюдатели смотрят. Чтоб никто не оскорбился. Вобщем я удалил посты своего мужского шовинизма. Но я это делаю исключительно из уважения к правилам комьюнити. Моё-же мнение остается моим.

На сколько сложно утроиться джуном на позицию C++ dev?

Вспоминается сразу весь пост-модерн Пелевина. SNUFF. "Сомелье" и наука как услуга. Я думаю имеет смысл изучать как работает ИИ чтобы встроиться в био-цепочку как можно ближе к раздаче денег.