Что можно использовать для хранения данных на компьютере с быстрым доступом?

Question

[up7]

Необходимо организовать хранение и поиск больших объемов данных на компьютере. Выбрал sqlite, но она очень медленно работает.

По сути данные - это набор строк. Ставить СУБД типа MySQL стоит? Там будут сотни миллионов строк.

Уточню. База будет из недлинных строк, потом будет пополняться ими. Пополнение только уникальными, не дубликатами.

В общем, даже пых с мускулем разочаровали( мне нужно было максимально быстрое слияние с уборкой дублей.

Победителями оказались обычные текстовые файлы и хэштаблицы (для отсева дублей).

Comments

[Иван Шумов]

Зависит от того что и как искать.

[up7]

Иван Шумов, строки. Недлинные. Необходимо пополнять будет базу, но не дубликатами. На вход файлы с сотнями тысяч строк. В итоге чтобы в базе были только уникальные.

[Иван Шумов]

up7, ни разу не сузили круг

[up7]

Иван Шумов, предположим, есть список слов. Далее заливаем еще сотню тысяч слов, база/система должна шустро отсеять дубликаты (то есть по слову) и занести только уникальные.

[Иван Шумов]

up7, это умеет делать вообще любая база на сегодня. С sqlite проблема в том что это не база, а, по факту, файл, который полностью перезаписывается

[d'Ivan]

up7, покажи свои медленные запросы и также схему БД с индексами.

[up7]

Роман Мирр, да там просто инсерты и одна таблица. Банально быстродействия не хватает.

[xmoonlight]

up7, а вставку одной строки - делаете одним запросом?

[d'Ivan]

up7, пароли или хэши паролей?

Answer 1

[mayton2019]

SQLite - это одна из быстрых DBMS. Если у тебя что-то медленно работает то наверное ты так написал запрос. Или такой набор индексов построил. Или тебе реально не хватает возможностей SQLite. Насколько я помню там некоторые опции не поддерживались типа CONNECT BY PRIOR и возможно оконные и аналитические функции тоже. Вобщем не стоит сразу ругать инструмент если ты точно не разобрался чего тебе именно не хватает. Ато перейдешь на OracleXE а там еще медленнее будет.

Answer 2

[xmoonlight]

На файлах - можно, но нужно знать, как правильно работать с конкурентными/параллельными потоками чтения и записи через файловый дескриптор.
(думаю, что тут можно разобраться)
Далее - про логику работы самой базы.

Алгоритм для файловой БД:
Отсортируйте список перед добавлением так, чтобы самые короткие уникальные сочетания символов - были в самом верху, а длиннее - чуть ниже.

В самом низу списка - максимально повторяющиеся сочетания по одному символу, затем 2-м и т.д., и в конце - по подряд идущим сочетаниям повторяющихся символов.

Создайте биграммные-триграммные кластеры на повторных сочетаниях.

При проверке на дубликат - спускаетесь вглубь по кластерному "дереву" (это и есть индексная карта ваших данных), используя файловое смещение узлов "дерева" (от узла к узлу) и получаете мгновенно вердикт: есть/нет проверяемое сочетание символов (например, уникальное слово или хеш-строка) в базе.