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