The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Посоветуйте что-нибудь быстрое иудобное для хранения пар текста, Аноним (0), 15-Янв-21, (0) [смотреть все]

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


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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру