Вариант для распечатки		Пред. тема | След. тема
Форум Программирование под UNIX (Python)
Изначальное сообщение		[ Отслеживать ]

"Посоветуйте что-нибудь быстрое иудобное для хранения пар текста"	+/–
Сообщение от Аноним (0), 15-Янв-21, 08:32
Здравствуйте. Нужно искать текст (в пределах 1 кб наверно) и возвращать из базы соответствующий ему другой текст (ещё несколько кб) если тот найден, в один поток одному пользователю. Хранится всё будет в файле на диске. Я собирался взять tokyocabinet, но у него биндинги что-то не очень живые. Желательно ещё иметь какое-нибудь разделение на категории, ну либо хранить категории в раздельных файлах но тогда доступ к куче файлов должен быть быстрый. Поиск должен быть максимально быстрым -пользователь и так ждёт слишком долго. Запись можно корутиной кидать, нормально будет я думаю. Скулите это конечно хорошо, но мне нет нужды в сикуле. Есть подозрение, что будет просаживаться когда база разрастётся на гигабайты, да и не очень удобно без алхимии. Спасибо.
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Посоветуйте что-нибудь быстрое иудобное для хранения пар текста"	+/–
Сообщение от Аноним (0), 15-Янв-21, 08:42
Бонус если очень быстро можно сравнить на совпадение без различий в пунктуации или хотя бы игнорировать различия вроде 。/. и （/( ну и …/... заодно.
Ответить | Правка | Наверх | Cообщить модератору

2. "Посоветуйте что-нибудь быстрое иудобное для хранения пар текста"	+/–
Сообщение от Аноним (0), 15-Янв-21, 13:18
Этот lmdb такая-то дрянь, ни cffi не работает, ни системный ни хочет, ни из pip не переопределить размер ключа. И по факту ограничено 2000 байт ключ + значение, иначе ты хочешь проблем. Потом, пухнет и не удаляет ничего, кошмарные объёмы места сжирает просто так… Вот leveldb вроде ок, пришлось поискать. Интересно, сколько можно данных запихнуть, прежде чем начнёт ощутимо тормозить.
Ответить | Правка | Наверх | Cообщить модератору

3. "Посоветуйте что-нибудь быстрое иудобное для хранения пар текста"	+/–
Сообщение от ыы (?), 16-Янв-21, 11:15
>[оверквотинг удален] > Я собирался взять tokyocabinet, но у него биндинги что-то не очень > живые. > Желательно ещё иметь какое-нибудь разделение на категории, ну либо хранить категории в > раздельных файлах но тогда доступ к куче файлов должен быть быстрый. > Поиск должен быть максимально быстрым -пользователь и так ждёт слишком долго. > Запись можно корутиной кидать, нормально будет я думаю. > Скулите это конечно хорошо, но мне нет нужды в сикуле. Есть подозрение, > что будет просаживаться когда база разрастётся на гигабайты, да и не > очень удобно без алхимии. > Спасибо. То есть у вас ключ длинной килобайт? Хм... бейте его на блоки по 100 байт засовывайте  иерархию в mapreduсe и за 10 хопов вы получите ответ  на любой запрос на любом размере базы.
Ответить | Правка | Наверх | Cообщить модератору

	4. "Посоветуйте что-нибудь быстрое иудобное для хранения пар текста"	+/–
	Сообщение от Аноним (0), 16-Янв-21, 11:42
	Мне надо чтобы это быстро работало. Ключ от 1 байта до 1500-2000 (в теории, но я точно знаю, что такие будут, потому что один символ утф-8 до 4 байт и даже до 6 в будущем). Интересует готовое решение на нативном языке. Сишный lmdb в принципе норм, только с питоновыми биндингами совсем беда. Плюсовый leveldb похуже, однако на моём кейсе вроде норм. Бонусом сжимает содержимое на диске, судя по бенчмаркам в интернете потребляет в 3 раза меньше места на несжимаемых данных, производительности пока что хватает, префиксы вроде то что нужно для разграничения данных (но только мне необходимо писать с разделением, а искать игнорируя префиксы, хм? так наверное нельзя, да?). Из минусов разве что ресурсоёмкость и вероятность развалить случайно. Интересно, а ситуации с кончившимся местом она переживёт нормально? Все браузеры теряют все ("временные") данные в таких условиях.
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Посоветуйте что-нибудь быстрое иудобное для хранения пар текста"	+/–
	Сообщение от Аноним (0), 16-Янв-21, 11:55
	С другой стороны, пройтись по всем префиксам будет ненамного дороже чем пройтись сразу по всем данным. Да, пожалуй leveldb пока подходит всем. HDF5 тоже рассматривался, но это очевидно уже оверкил будет.
	Ответить | Правка | Наверх | Cообщить модератору

	6. "Посоветуйте что-нибудь быстрое иудобное для хранения пар текста"	+/–
	Сообщение от Аноним (0), 16-Янв-21, 11:58
	Хотя хотелось бы замерить. Префиксов больше 1000 на базу не планируется пока что.
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Посоветуйте что-нибудь быстрое иудобное для хранения пар текста"	+/–
	Сообщение от Аноним (0), 16-Янв-21, 12:01
	Но сколько времени потеряется при допустим 100 базах по 1000 префиксов? 1 ключом по 100 базам должно быть заметно проще чем пройтись 1 ключом по 100000 "баз".
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Посоветуйте что-нибудь быстрое иудобное для хранения пар текста"	+/–
	Сообщение от ыы (?), 16-Янв-21, 12:06
	> Мне надо чтобы это быстро работало. Возьмите Майкрософт SQL Server (он есть бесплатный), и постройте по своей табличке кластеризованный индекс. быстродействие и иерархическое дерево "на нативном языке" прилагается бесплатно.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема