После двух месяцев разработки состоялся выпуск библиотеки libmdbx 0.9.3 (MDBX) с реализацией высокопроизводительной, компактной встраиваемой базы данных класса ключ-значение. Код libmdbx распространяется под лицензией OpenLDAP Public License. libmdbx является глубокой переработкой СУБД LMDB и по заявлению разработчиков превосходит своего прародителя по надежности, набору возможностей и производительности. Заявляется, что libmdbx до 20% быстрее LMDB в CRUD сценариях, и до 30% быстрее если при сборке libmdbx отключить внутренний контроль до сопоставимого с LMDB уровня...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54554
Это как berkeley db?
> Это как berkeley db?Смотря что подразумевать под этим "как".
Согласно википедии (https://en.wikipedia.org/wiki/Embedded_database#Oracle_Berke...) последнее время наблюдается массовый переход с Berkeley DB на LMDB, поскольку второе меньше глючит и работает быстрее. Ну и плюс изменение лицензии.
За вычетом лицензии, наверное, главная проблема Berkeley DB в кешировании: большие накладные расходы, глюки и деадлоки - всё с момента появления этого кеширования.
Тем не менее, в Berkeley DB есть немало фичей отсутствующих в LMDB (тут не добавляли не затребованного). Эти фичи кому-то могут быть крайне важны, но одновременно превращают Berkeley DB в монструозный легасу-комбайн.
---
Ну и соответственно MDBX - это "улучшенная" LMDB. Но важно что кроме "улучшений" в libmdbx устранено достаточно багов (пример проявления https://github.com/ledgerwatch/turbo-geth/issues/1473).
вопрос из 4-х (четырёх!) слов... Ответ такого объёма, что первая мысль -- иди на [запрет в интернете]
> вопрос из 4-х (четырёх!) слов... Ответ такого объёма, что первая мысль --
> иди на [запрет в интернете]Дак идите, не задерживайте очередь
До BerkeleyDB этому поделию, как до Луны раком. Оно даже на база данных, а обычный ретривер. BerkeleyDB поддерживает ISAM и полностью ACID. Это единственная нормальная не SQL база данных.
> До BerkeleyDB этому поделию, как до Луны раком.
> Оно даже на база данных, а обычный ретривер.Без обид, но чушь.
Видимо от незнания/недопонимания.> BerkeleyDB поддерживает ISAM и полностью ACID. Это
> единственная нормальная не SQL база данных.Так было лет ~30 назад. Процитирую аргументацию, которую не нашлось кому опровергнуть:
BerkeleyDB — очень старый продукт в области, которая активно развивалась в последнее время, перенесла несколько революций и родила массу альтернатив с учетом набитых шишек. Лучшее враг хорошего и сейчас при (пожалуй) любом наборе критериев можно выбрать альтернативу превосходящую BerkeleyDB. К этому добавляется ряд проблем/недочетов: плохая производительность и/или deadlock-и при конкурентной обработки транзакций, полу-ручное восстановление БД после падений, смена лицензии на AGPL (неприемлема для некоторых проектов).
BerkeleyDB является встраиваемым движком хранения, но предлагает больше чем key-value. В результате получился комбайн, у которого что-то не так с каждой из features. Поэтому в последние годы (несмотря на усилия и деньги Oracle) разработчики предпочитают мигрировать с BerkeleyDB, когда им нужна хотя-бы одна features (производительность, надежность, масштабируемость, репликация, шифрование и т.д.) на актуальном для индустрии уровне.
Сомнительным, но всё-же аргументом, стало то, что при всей "чудесности" BerkeleyDB (исходя из проспектов Oracle) удаленный из MySQL 5.1 бэкенд хранение так и не был возвращен (работы и багов много, а толку нет).
--
В подтверждение, по списку https://en.wikipedia.org/wiki/Berkeley_DB#Past_users (который далеко не полный) видно, что от BerkeleyDB бегут все кому нужно что-то не-глючное, надежное и производительное.
А если сравнивать MDBX/LMDB c BerkeleyDB, то в той-же Википедии также неплохо сформулировано:
"... over recent years many well-known projects switched to using LMDB, because it outperform Berkeley DB in key scenarios on the ground of "less is more" design, as well due to the license changing."
Отсюда https://en.wikipedia.org/wiki/Embedded_database#Oracle_Berke...
Судя по патчу для порта FreeBSD, написано крайне непрофессионально.
Ишвините, возможно не по адресу, но чем оно лучше leveldb? Понятно что leveldb не самая надёжная и устойчивая к поврежденями, кроме того у неё значительные футпринт и оверзхэд в рантайме, но помимо этого? А то lmdb что-то совсем никуда не годится.
> чем оно лучше leveldb?Это разные движки, с принципиально различным внутренним устройством, т.е. теплое и мягкое.
> Понятно что leveldb не самая надёжная и устойчивая к поврежденями, кроме того у неё значительные футпринт и оверзхэд в рантайме, но помимо этого?
Дедушку levedb конечно пора отпустить, если только нет противопоказаний (например) от RocksDB.
Если же сравнивать MDBX (b+tree и ACID поверх MVCC за счет page shadowing) и RocksDB (LSM tree с "бантиками"), то минусы каждого из движков могут с запасом перекрыть плюсы в зависимости от сценариев и условий использования.
Т.е. если вам нужен "утюг", то подойдет одно, а если "подушка" - то другое.При этом, для желающего понять как внутреннее устройство MDBX и RocksDB, так и для каких сценариев использования они (не)подходят - в Сети полно информации.
> А то lmdb что-то совсем никуда не годится.ТТХ и поведение LMDB отлично соответствует целевым сценарием использования этого движка.
Поэтому оно очень даже годится с двумя оговорками:
1) в LMDB ребусный стиль кодирования, (как следствие) высокий порог вхождения и относительно малое кол-во людей готовых что-либо поправить с SLA.
= в MDBX это осталось, ибо иначе нужно "переписать".2) в LMDB отсутствуют полноценные тесты и средства проверки целостности БД, (как следствие) баги приводящие к повреждению БД и/или потерям данных
= в MDBX это полностью устранено.
> Это разные движки, с принципиально различным внутренним устройством, т.е. теплое и мягкое.Если будете делать такие заявления, я сейчас начну сравнивать MDBX и HDF5, и скорее всего даже не придётся долго подбирать кейсы на которых последняя окажется предпочтительнее.
>> Это разные движки, с принципиально различным внутренним устройством, т.е. теплое и мягкое.
> Если будете делать такие заявления, я сейчас начну сравнивать MDBX и HDF5, и скорее всего даже не придётся долго подбирать кейсы на которых последняя окажется предпочтительнее.Т.е. вы считаете что MDBX и RocksDB схожи насколько, что метафора "теплое и мягкое" не подходит?
Просветите тогда уж меня убогого.
Нет. Я считаю, что это всё совершенно не интересно пользователям, имеют значение только осязаемые параметры. И вот скажем это "ура, мы на 5% быстрее на узкоспецифичных кейсах!" не тянет на конкурентное преимущество. По многим пользовательским параметрам rocks и lmdb проигрывают leveldb, во всяком случае так было неделю назад, когда я крайний раз выбирал key-value хранилище для проекта. Может быть, с тех пор что-нибудь и поменялось.
отредактировано/удалено: кот прыгнул на тачпад...
>[оверквотинг удален]
> быстрее на узкоспецифичных кейсах!" не тянет на конкурентное преимущество. По многим
> пользовательским параметрам rocks и lmdb проигрывают leveldb, во всяком случае так
> было неделю назад, когда я крайний раз выбирал key-value хранилище для
> проекта. Может быть, с тех пор что-нибудь и поменялось.
> Нет. Я считаю, что это всё совершенно не интересно пользователям, имеют значение
> только осязаемые параметры. И вот скажем это "ура, мы на 5%
> быстрее на узкоспецифичных кейсах!" не тянет на конкурентное преимущество. По многим
> пользовательским параметрам rocks и lmdb проигрывают leveldb, во всяком случае так
> было неделю назад, когда я крайний раз выбирал key-value хранилище для
> проекта. Может быть, с тех пор что-нибудь и поменялось.1) Позвольте пожелать удачи вашему (похоже воображаемому) "проекту".
2) Не 5%, а до 30%. Не в "узкоспециализированных кейсах", а в CRUD-сценариях с псевдо-случайным порядком записей.
По ссылкам, кроме _ВСЕХ_ исходных текстов, легко найти примечание: 2 inserts, 1 read, 1 update, 1 delete.3) Ничего не поменялось примерно с самого начала.
Что-чему проиграет/выиграет принципиально зависит от требований, например:
- сколько процессов работают с БД;
- нужны ли транзакции и с какой изоляцией;
- отношение read/write в нагрузке;
- ограничения на выброс latency;
- нужны ли выборки диапазонов;
- как долго живут версии данных;
- отношение объема данных и ОЗУ;
- какие диски;
- и т.д.Короче, просится RTFM:
https://github.com/erthink/libmdbx#performance-comparison
https://github.com/erthink/libmdbx#comparison-with-other-dat...
Спасибо за очередное напоминание почему стоит держаться подальше от руснявых разработчиков. Хотя, конечно, хамство в ответ на вопросы - это нормально для них, можно и привыкнуть давно было. По ссылке какой-то маркетинговый булшит, нужны нормальные исследования и оценки.
> Спасибо за очередное напоминание почему стоит держаться подальше от руснявых разработчиков. Хотя, конечно, хамство в ответ на вопросы - это нормально для них, можно и привыкнуть давно было. По ссылке какой-то маркетинговый булшит, нужны нормальные исследования и оценки.Хамство от вас с самого начала и особенно здесь, а булшит в вашем нежелании вникать в информацию.
Смотрите любые бенчмарки LMDB и делайте поправку на дополнительные фичи MDBX и "до 30%" прироста производительности.
https://symas.com/lmdb/technical/
Угу. Это звучит как: "Показать нам нечего, мы ничего не можем, найдите там что-нибудь и прикиньте что-нибудь к чему-нибудь сами, может быть на что-нибудь будет похоже". Но если это ровно та же lmdb, то очевидно, что выбор будет сделан в пользу rocks (либо leveldb).
> Угу. Это звучит как: "Показать нам нечего, мы ничего не можем, найдите
> там что-нибудь и прикиньте что-нибудь к чему-нибудь сами, может быть на
> что-нибудь будет похоже". Но если это ровно та же lmdb, то
> очевидно, что выбор будет сделан в пользу rocks (либо leveldb).Еще раз для одарённых:
- в README есть результаты бенчмарков, со всеми исходниками и сценариями.
- в README есть список наиболее значимых фич MDBX отсутствующих в LMDB.
- в Сети есть масса результатов, статей и сравнений LMDB.
- в GNUMakefile есть цель для запуска бенчмарков, позволяющая в частности сравнить MDBX и LMDB, т.е. увидеть разницу.При этом нет цели убедить каждого анонимного недооцененного гения в том, что ему нужно, или не нужно, использовать MDBX, LMDB, RocksDB либо что-то еще.
Вам нужно самостоятельно изучать тему, делать выбор и расплачиваться за ошибки.
Не вижу смысла продолжать. В будущем прошу воздержаться от ответов мне, я рассчитываю на ответы других участников. Которые будут иметь хоть какую-то полезную нагрузку, в отличие от вот этого.
Ещё и минусы проставляет при каждом ответе, а себя плюсует. Ну это уже совсем клиника.
> Ещё и минусы проставляет при каждом ответе, а себя плюсует. Ну это
> уже совсем клиника.А так можно было? ща воспользуюсь ;)
Умилительное притворство, да. Нет.
> Умилительное притворство, да. Нет.А может кто-нибудь просветить с алгоритмами работы движка форума.
Ну т.е. действительно можно голосовать за себя и многократно?
Не знаю насчёт многократно, но оценки появлялись через в течении пары минут и были очень уж односторонние. И это было не единожды. Возможно это тайный поклонник, конечно, а больше в этой новости некому обитать. Поэтому спишем на притворство.
> а больше в этой новости некому обитатьЭй там, еще и я тут есть! Читать предметные посты тов. erthink было очень приятно несмотря на то что мои глубокие познания устройства БД заканчиваются как раз на BDB и LevelDB
А вот посты анона было не приятно читать, т.к. они бессодержательны и лишь отняли моё время.
минусы тебе, хамлу тyпopылому, ставлю я в том числе
> Если будете делать такие заявления, я сейчас начну сравнивать MDBX и HDF5, и скорее всего даже не придётся долго подбирать кейсы на которых последняя окажется предпочтительнее.так сравни, с диагнозом сразу станет понятно ;)
Ужасно сложно выражаешь свои мысли
он и код пишет такой-же, даже говард чу не осиливает.
> LSM tree с "бантиками"Каким еще "бантиками"?
>> LSM tree с "бантиками"
> Каким еще "бантиками"?https://github.com/facebook/rocksdb/wiki/Features-Not-in-Lev...
это все, конечно, да... а где в каких продуктах PT она используется?
https://github.com/PositiveTechnologies/libfpta внутри https://www.ptsecurity.com/ru-ru/products/mpsiem/
const uint64_t cadabra =
rrxmrrxmsx_0(*abra + UINT64_C(7680760450171793) * (unsigned)mdbx_getpid())качество кода зашкаливает
> const uint64_t cadabra =
> rrxmrrxmsx_0(*abra + UINT64_C(7680760450171793) * (unsigned)mdbx_getpid())
> качество кода зашкаливаетНе знакомы с иньективными отображениями и примитивами/миксерами хеш-функций?
Но я подскажу вам где действительно стоит критиковать - см. код функции mdbx_update_gc().
Это действительно то, что Howard Chu не стал осиливать ;)А если "понравится", то начните с https://github.com/LMDB/lmdb/tree/mdb.master/libraries/liblm...
Вполне очевидно, что речь про:> cadabra
> rrxmrrxmsx_0а не константы хэшей - которые, впрочем, тоже можно было вынести в макросы.
>Вполне очевидно, что речь про:
>> cadabra
>> rrxmrrxmsx_0
>а не константы хэшей - которые, впрочем, тоже можно было вынести в макросы.Это (пожалуй) предельно простой и прозрачный фрагмент кода, примерно как hello world, но не пример из учебника.
Его читаемость улучшит только знание что такое rrxmrrxmsx и чем может быть константа, а не приседания с вынесением "магических" констант в макросы.
Поэтому, пожалуйста, не надо делать что-то вроде code review настолько беспощадно (к себе).
Тем не менее, если вы хотите облагородить какие-то фрагменты кода, то я с радостью приму PR.
> rrxmrrxmsx_0Нет бы взяли да назвали RotateRotateXorMultiplyRotateRotateXorMultiplyShiftXor_0, да. Это общепринятые сокращения, а не авторский стиль.
А не подскажете, для сценария, однопоточного чтения/записи, с очень редкими записями из других потоков, какая KV-бд подойдёт? Надо максимизировать скорость.
> А не подскажете, для сценария, однопоточного чтения/записи, с очень редкими записями из
> других потоков, какая KV-бд подойдёт? Надо максимизировать скорость.Если данные помещаются в ОЗУ и чтения существенно больше чем записи, то MDBX может быть очень неплохим вариантом:
- чтения будут неблокируемыми, OlogN и со скоростью доступа в память, и на каждом ядре CPU.
- редкие пишущие транзакции можно делать no-sync и сбрасывать на диск асинхронно (вызывая mdbx_env_sync из отдельного треда).
RocksDB также стоит примерить, особенно если какая-либо фича может вам помочь (например фильтр Блума).Но в целом может подойти очень многое и надо внимательно смотреть на все остальные аспекты.
спасибо
mdbx.c++
mdbx.h++"Быть не как все" снова детектед.
Очень хорошо . Только если рискнули на гитхабной помойке разрабатывать - закройте возможность гадить в код кому попало иначем мы вас потеряем очень скоро.
> Please don't use my work, if you are associated with Adolf Hitler, Stepan Bandera, George Soros, Michael Hodorkovsky, either support an actions of these felons.Одобрямс. Надо лицензию придумать чтоб копрорации не имели право использовать код, есть идеи ?
Да, хорошо бы такое ... выпиливать с гитхаба. Предлагаю флешмобчик в виде абьюзов. =)
Ставить Ходорковского в один ряд с Гитлером -- это знать про Ходорковского из пропагандистских СМИ. А вообще в свободных лицензиях не должно быть ничего такого конечно же. Навязывать свои тараканы чужим -- это уже не свободная лицензия.
> Ставить Ходорковского в один ряд с Гитлером -- это знать про Ходорковского
> из пропагандистских СМИ.Ваше мнение является следствием других пропагандистских СМИ.
Тем не менее, там нет явного знака равенства (т.е. не нужно передергивать), а ограничение на длину не позволяет что-либо уточнить.> А вообще в свободных лицензиях не должно быть
> ничего такого конечно же. Навязывать свои тараканы чужим -- это уже
> не свободная лицензия.Читайте внимательно.
Это просьба, а не часть лицензий (которые явно указаны внутри каждого проекта).
>а ограничение на длину не позволяет что-либо уточнить.
> Ваше мнение является следствием других пропагандистских СМИ.Скорее собственного небольшого исследования на эту тему. При участии СМИ конечно же, но скорее как для получения дополнительного набора ссылок для уточнения.
> там нет явного знака равенства
Я и не говорил, что он там есть.
> Это просьба, а не часть лицензий (которые явно указаны внутри каждого проекта).
Я и не говорил "убрать из лицензии" или как либо иначе о том, что оно есть в лицензии. Я лишь говорю, что такого в свободных лицензиях быть не должно.
Читайте внимательнее.
>лицензию придумать чтоб копрорации не имели право использовать кодGNU GPL
Ты читать умеешь ?ИСПОЛЬЗОВАТЬ, не только закрывать
А где граница между корпорацией и ООО из двух человек?
> Очень хорошо . Только если рискнули на гитхабной помойке разрабатывать - закройте
> возможность гадить в код кому попало иначем мы вас потеряем очень
> скоро.Не понял что вы хотели сказать.
В код кому-то гадить крайне сложно, нужны явные разрешения и некое понимание кода.Ну и никакой особой разработки на github нет, это просто удобная и общеизвестная площадка, которая используется для:
- раздачи кода.
- взаимодействия с пользователями библиотеки и накопления "ачивок" (гитхабовых звездочек).
- прогона CI-тестов на условиях "для open source".А после блокировки Крыма основным репо считается https://abf.io/erthink/libmdbx, о чем добавлены примечания.
> Не понял что вы хотели сказать.
> В код кому-то гадить крайне сложно, н общеизвестная площадкаОбщественный сартир. Никогда не знаешь какой баг тебе завезут "случайно" под видом поддержки windoz (кстати поддержку оно лучше выпилить в идеале не заявлять изначально). У меня уже музей проектов которые мы потеряли. То тут вдруг и неожиданно пофиксили что работать стало в тысячи раз медленнее, то тум вдруг буфер стал вылазить и ни один санитайзер не видит этого. Могу только посоветовать если не плевать на свое творчество (которое потеряешь когда принимаешь чужие комиты, точнее они становятся совладельцами и могут сыграть с тобой в демократические выборы, и всем будет чьхать что ты 99.9999% кода написал) .
Хороший же проект, опомнись пока не поздно !
> Хороший же проект, опомнись пока не поздно !Все несколько проще:
- MDBX основывается на LMDB, поэтому лицензию уже не изменить (OpenLDAP Public License), вне зависимости от (не)принятия каких-либо коммитов.
- что касается MithrilDB, то вне зависимости от лицензии там будет Contribution Agreement.Тем не менее, модель Open Source, как таковая, имеет свои как плюсы, так и минусы...
> MithrilDBAdamantiumDB тоже свободно!
Вроде бы взрослый человек...
>> MithrilDB
>AdamantiumDB тоже свободно!
>Вроде бы взрослый человек...Так это же для пользователей, а они как дети - хотят тесла, яблоки всякие...
Но на всех не угодишь - тут вот какому-то дитяте тайтл "libmdbx" не нравился, а вам "мифрил".
Короче, сделайте усилие и привыкайте ;)
Ну да, ну да. Это пользовательское бессознательное шутить изволит.
Побойтесь Зевса!
> А после блокировки Крыма основным репо считается https://abf.io/erthink/libmdbx, о чем добавлены > примечания.Это просто камни с неба! Но им то что? Они же в родной гавани!
В подвале сайта стоитROSA Lab © 2021
при этом и rosalab.com, и rosalinux.com недоступны. Хотя жив wiki.rosalab.com - подправили бы подвал, что ли...
> при этом и rosalab.com, и rosalinux.com недоступны. Хотя жив wiki.rosalab.com - подправили бы подвал, что ли...РОСА всегда жила в зоне *.ru, а не *.com
>> при этом и rosalab.com, и rosalinux.com недоступны. Хотя жив wiki.rosalab.com - подправили бы подвал, что ли...
> РОСА всегда жила в зоне *.ru, а не *.comНу тогда им точно нужно малость починить сайт. На главной
в подвале стоит вот что:
[a href="http://www.rosalab.com/about"]About the company[/a]
(нормальные теги по понятной причине поставить не могу)
Субдб либмдбх. Высокопроизводительный. Скороговорка. После 3-х стаканов.
> Субдб либмдбх. Высокопроизводительный. Скороговорка. После 3-х стаканов.Есть еще и "t1ha", так что лучше не пейте (тем более стаканами).
erthink, а API по сравнению с lmdb сильно изменено? Чем-то вроде https://github.com/lmdbjava/lmdbjava удастся воспользоваться или биндинг самому писать придется?
> erthink, а API по сравнению с lmdb сильно изменено? Чем-то вроде https://github.com/lmdbjava/lmdbjava
> удастся воспользоваться или биндинг самому писать придется?API существенно расширено и в паре мест принципиально изменено (время жизни и требования явно закрывать курсоры, время жизни DBI хендлов).
Но всё такие изменения (включая причины) описаны в доке.Поэтому биндинги на 95% получаются путем замены префиксов.
Кроме этого, в README есть ссылки на существующие привязки. Там есть и для Явы, хотя порядком протухшие.
Есть от чего оттолкнуться.
Спасибо. Разбираться и писать самому увы, времени нет...
Если вдруг сподвигнитесь на собственные байдинги, то большая просьба глянуть на новое C++ API и "повторить на яве" ради унификации. При этом сейчас ещё можно обсуждать и встречно менять плюсовое API.
Поклонники Сороса, Ходорковского и Бандеры не используют Ваши продукты?
Они очень страдают морально и финансово, но нет. Не используют.
Почему Miranda NG переходит на SQLite, если MDBX так хороша?
> Почему Miranda NG переходит на SQLite, если MDBX так хороша?Насколько мне известно, там не переход, а добавление еще одного драйвера хранения.
Тем не менее, история такая:
1.
До каких-то последних версий (если не ошибаюсь, в январе этого 2021 года) libmdbx внутри Miranda NG использовалась некорректно, из-за чего пользователи теряли данные.
Пользователи считали что причина проблем в MDBX, ругались и активно просили добавить еще один драйвер хранения.Суть проблемы была в том, что БД явно и намеренно открывалась в небезопасном режиме (без гарантий сохранности данных при системном сбое, выключении питания и т.п).
Это неоднократно было пояснено разработчикам, но они считали что риски мизерны и долго не могли сподвигнуться на переделку своего кода.Следы этих обсуждений и моих пояснений/комментариев есть как в https://github.com/miranda-ng/miranda-ng/issues, так и на форуме Miranda NG http://forum.ru-board.com/topic.cgi?forum=5&topic=34402
2.
Примерно за год до этого (до февраля 2020 года), в драйвере Miranda NG были какие-то баги, из-за которых в БД записывались неверные данные.
Подробностей я не помню, но они есть в истории коммитов Miranda NG и в issues проекта на github.3.
Еще примерно за год до этого (до февраля 2019 года) было две неприятности именно в libmdbx:- Из-за моей оплошности в миранду (и далее к пользователям) исходно попала "девелоперская" версия, которая намерено делалась несовместимой по формату БД с релизами (чтобы в production не попадали экспериментальные фичи).
Эту проблему огораживали как могли, но пользователей она конечно злила.- Был обнаружен и устранен унаследованный из LMDB баг, который мог приводить к повреждению БД.
Возможно этот баг также затронул пользователей миранды, но субъективно проблемы были от описанного выше.--
В libmdbx при этом много чего было сделано для лучшей поддержки Windows, включая даже поддержку Windows 2000/XP и работу под Wine.
В следующем выпуске именно переход, т.к. mdbx-базы будут только читаться, создавать новые уже запрещено.
Две причины:- изначально хотели таки на SQLite, но не было идей, как сделать его достаточно быстрым для нужд Миранды. Поэтому, взяли то, что было уже быстрым, а потом за годы неспеша реализовали поддержку курсоров и, в целом, достаточно ускорили работу SQLite.
- под SQLite есть тонна внешних утилит для работы с базами, пользователи это очень хотят