Здравствуйте.Нужно искать текст (в пределах 1 кб наверно) и возвращать из базы соответствующий ему другой текст (ещё несколько кб) если тот найден, в один поток одному пользователю. Хранится всё будет в файле на диске. Я собирался взять tokyocabinet, но у него биндинги что-то не очень живые.
Желательно ещё иметь какое-нибудь разделение на категории, ну либо хранить категории в раздельных файлах но тогда доступ к куче файлов должен быть быстрый. Поиск должен быть максимально быстрым -пользователь и так ждёт слишком долго. Запись можно корутиной кидать, нормально будет я думаю.
Скулите это конечно хорошо, но мне нет нужды в сикуле. Есть подозрение, что будет просаживаться когда база разрастётся на гигабайты, да и не очень удобно без алхимии.
Спасибо.
Бонус если очень быстро можно сравнить на совпадение без различий в пунктуации или хотя бы игнорировать различия вроде 。/. и （/( ну и …/... заодно.
Этот lmdb такая-то дрянь, ни cffi не работает, ни системный ни хочет, ни из pip не переопределить размер ключа. И по факту ограничено 2000 байт ключ + значение, иначе ты хочешь проблем. Потом, пухнет и не удаляет ничего, кошмарные объёмы места сжирает просто так…Вот leveldb вроде ок, пришлось поискать. Интересно, сколько можно данных запихнуть, прежде чем начнёт ощутимо тормозить.
>[оверквотинг удален]
> Я собирался взять tokyocabinet, но у него биндинги что-то не очень
> живые.
> Желательно ещё иметь какое-нибудь разделение на категории, ну либо хранить категории в
> раздельных файлах но тогда доступ к куче файлов должен быть быстрый.
> Поиск должен быть максимально быстрым -пользователь и так ждёт слишком долго.
> Запись можно корутиной кидать, нормально будет я думаю.
> Скулите это конечно хорошо, но мне нет нужды в сикуле. Есть подозрение,
> что будет просаживаться когда база разрастётся на гигабайты, да и не
> очень удобно без алхимии.
> Спасибо.То есть у вас ключ длинной килобайт? Хм... бейте его на блоки по 100 байт засовывайте иерархию в mapreduсe и за 10 хопов вы получите ответ на любой запрос на любом размере базы.
Мне надо чтобы это быстро работало. Ключ от 1 байта до 1500-2000 (в теории, но я точно знаю, что такие будут, потому что один символ утф-8 до 4 байт и даже до 6 в будущем). Интересует готовое решение на нативном языке. Сишный lmdb в принципе норм, только с питоновыми биндингами совсем беда. Плюсовый leveldb похуже, однако на моём кейсе вроде норм. Бонусом сжимает содержимое на диске, судя по бенчмаркам в интернете потребляет в 3 раза меньше места на несжимаемых данных, производительности пока что хватает, префиксы вроде то что нужно для разграничения данных (но только мне необходимо писать с разделением, а искать игнорируя префиксы, хм? так наверное нельзя, да?). Из минусов разве что ресурсоёмкость и вероятность развалить случайно. Интересно, а ситуации с кончившимся местом она переживёт нормально? Все браузеры теряют все ("временные") данные в таких условиях.
С другой стороны, пройтись по всем префиксам будет ненамного дороже чем пройтись сразу по всем данным. Да, пожалуй leveldb пока подходит всем. HDF5 тоже рассматривался, но это очевидно уже оверкил будет.
Хотя хотелось бы замерить. Префиксов больше 1000 на базу не планируется пока что.
Но сколько времени потеряется при допустим 100 базах по 1000 префиксов? 1 ключом по 100 базам должно быть заметно проще чем пройтись 1 ключом по 100000 "баз".
> Мне надо чтобы это быстро работало.Возьмите Майкрософт SQL Server (он есть бесплатный), и постройте по своей табличке кластеризованный индекс.
быстродействие и иерархическое дерево "на нативном языке" прилагается бесплатно.