- you can embed it to your software and it just works (HyperSQL)
— you can unit test your DB Schemas and actual queries quite easily with (almost) plain Java code. (всё семейство)
Есть ли ещё какие-то возможные соображения для использования чисто-управляемой СУБД?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Эйнсток Файр, Вы писали:
S>> Наткнулся тут на упоминание ажно трёх СУБД на чистой Java: HSQLDB, H2, и Derby.
ЭФ>На C# их тоже три штуки. Одна оригинальная — deveeldb называется
Прикольно, спасибо!
А какие две остальные?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Наткнулся тут на упоминание ажно трёх СУБД на чистой Java: HSQLDB, H2, и Derby.
Ничего себе ты отстал от мира. ))) Этого добра же давным давно полно, в том числе и весьма известного. Например та же Cassandra, на которой очень много серьёзных проектов.
И да, их потом частенько переписывают на C++ (см. например Scylla, для Cassandra), получая увеличение быстродействия в разы. Но при этом многие продолжают использовать изначальную Java разновидность (хотя они полностью совместимы), видимо из соображений "работает — не трогай!". )))
S>Сходу не смог найти никаких обоснований их существованию. S>Ну, вот к примеру, https://stackoverflow.com/questions/3664882/pure-java-sqlite-library/3664957#3664957 упоминает два сценария: S>
S>- you can embed it to your software and it just works (HyperSQL)
S>- you can unit test your DB Schemas and actual queries quite easily with (almost) plain Java code. (всё семейство)
S>Есть ли ещё какие-то возможные соображения для использования чисто-управляемой СУБД?
Ну встраиваемые СУБД — это вообще отдельный вопрос и вполне понятно зачем они написаны и существуют (всё же подключать нативный код в Java не особо удобно). Т.е. эти то даже никто переписывать не будет, т.к. они выполняют свою основную задачу именно своим Java-кодом.
Здравствуйте, alex_public, Вы писали:
_>И да, их потом частенько переписывают на C++ (см. например Scylla, для Cassandra), получая увеличение быстродействия в разы. Но при этом многие продолжают использовать изначальную Java разновидность (хотя они полностью совместимы), видимо из соображений "работает — не трогай!". )))
Да нет тут никакого секрета: https://www.scylladb.com/pricing/
Просто в быстродействие кассандры (и вообще субд) упираются далеко не все, вот и сидят на бесплатном и более простом решении, чем go native.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
S>- you can embed it to your software and it just works (HyperSQL)
S>- you can unit test your DB Schemas and actual queries quite easily with (almost) plain Java code. (всё семейство)
S>Есть ли ещё какие-то возможные соображения для использования чисто-управляемой СУБД?
Я один раз использовал в качестве "умного" временного файла. А так смысла лично я не вижу. Для тестов надо использовать настоящую БД, иначе это будут не тесты, а чёрт-те что. Для продакшна Sqlite давно стала стандартом де-факто и надо использовать именно её, пусть и через JNI, не важно, это слишком хороший проект, чтобы можно было сделать что-то лучше.
S>- you can embed it to your software and it just works (HyperSQL)
S>- you can unit test your DB Schemas and actual queries quite easily with (almost) plain Java code. (всё семейство)
На прошлой работе именно так H2 использовали: для тестов и для запуска продукта в режиме "разработки". Взял исходники, запустил, всё работает, что тесты, что продукт; не требует никакой настройки и установки. Особенно, с учётом того, что нативный код в Java не очень удобно встраивать, да плюс ещё разработчики то на Linux, то на Windows, то вообще на macOS. Тесты вообще in-memory вариант использовали, тесты кончились, база исчезла.
В реальных установках, конечно, использовали Oracle или SQL Server. Отличия H2 от "настоящих" СУБД, конечно, были, но выгода покрывала затраты (особенно, с учётом того что и так под две базы приходилось прогибаться).
S>Сходу не смог найти никаких обоснований их существованию. S>Есть ли ещё какие-то возможные соображения для использования чисто-управляемой СУБД?
Избежать кросс-процессных и кросс-доменных вызовов. Как от клиента к СУБД, так и от СУБД к юзерским ХП.
Здравствуйте, Sinclair, Вы писали:
S>Есть ли ещё какие-то возможные соображения для использования чисто-управляемой СУБД?
Например, мы использовали для того, чтобы хранить локальную копию данных для того, чтобы каждый запрос не гонять на сервер. На сервере был Postgres, на клиенте H2, интерфейс был через Hibernate, так что запросы были портабельны.
Сейчас вот прямо использую для того, чтобы хранить копию погодных данных для всех погодных станций в мире непосредственно в виде одного большого файла, который зашивается в образ Docker.
Здравствуйте, vsb, Вы писали:
vsb>Я один раз использовал в качестве "умного" временного файла. А так смысла лично я не вижу. Для тестов надо использовать настоящую БД, иначе это будут не тесты, а чёрт-те что. Для продакшна Sqlite давно стала стандартом де-факто и надо использовать именно её, пусть и через JNI, не важно, это слишком хороший проект, чтобы можно было сделать что-то лучше.
Одно другому не мешает. Понятно, что перед релизом нужно поднять тестовый кластер, максимально приближенный к боевой базе.
Но это долго и дорого. А хочется гонять тесты часто и быстро.
Поэтому для разработки очень удобно иметь небольшую in-memory db с мимнимальными затратами на разогрев.
Здравствуйте, Блудов Павел, Вы писали:
vsb>>Я один раз использовал в качестве "умного" временного файла. А так смысла лично я не вижу. Для тестов надо использовать настоящую БД, иначе это будут не тесты, а чёрт-те что. Для продакшна Sqlite давно стала стандартом де-факто и надо использовать именно её, пусть и через JNI, не важно, это слишком хороший проект, чтобы можно было сделать что-то лучше.
БП>Одно другому не мешает. Понятно, что перед релизом нужно поднять тестовый кластер, максимально приближенный к боевой базе. БП>Но это долго и дорого. А хочется гонять тесты часто и быстро. БП>Поэтому для разработки очень удобно иметь небольшую in-memory db с мимнимальными затратами на разогрев.
Никогда не получалось так. Это только если совсем не использовать фичи нормальной БД, чтобы оставалась совместимость. Мне больше нравится вариант с докер контейнером, в котором один раз инициализируются БД и схема, а перед каждым тестом он просто запускается и потом состояние выкидывается.
Здравствуйте, Sinclair, Вы писали:
S>Есть ли ещё какие-то возможные соображения для использования чисто-управляемой СУБД?
Их удобно использовать, если хочется поработать с реляционной моделью сформированной на ходу, например из логов, потоковых данных и прочих гетерогенных источников? В Питоне есть еще pandas, но иногда тот же sqlite из коробки проще и удобней. В управляемом языке нативных библиотеках избегают по понятным причинам.
