Re[5]: Какую СУБД выбрать? - Базы данных

Здравствуйте!

Каких-то особых требований нет, и я бы наверное предпочёл SQLite, но он вроде не даёт одновременного доступа к одной БД из разных процессов. Хочется что-то такое же легко, не требующее отдельной установки, чтобы можно было с собой и базу и движок таскать, но позволяющее шарить БД между процессами

UPD Сорян, что-то забыл вот еще что. От самой СУБД сказал что хочу, а вот то, что я хочу из джавы и из плюсиков использовать — забыл. Из джавы — много-много писатель и редко-редко читатель, из плюсиков — наоборот

UPD2 Ещё сорян, мне нужно под винду тока

Здравствуйте, Marty, Вы писали:

M>Каких-то особых требований нет, и я бы наверное предпочёл SQLite, но он вроде не даёт одновременного доступа к одной БД из разных процессов. Хочется что-то такое же легко, не требующее отдельной установки, чтобы можно было с собой и базу и движок таскать, но позволяющее шарить БД между процессами

А если коннекшн закрывать после запроса?

Здравствуйте, Marty, Вы писали:

M>Каких-то особых требований нет,
Раз требований нет, бери любую

M>Хочется что-то такое же легко, не требующее отдельной установки, чтобы можно было с собой и базу и движок таскать, но позволяющее шарить БД между процессами
Ну и бери SQLite, вот тут пишут

Yes SQLite can support multiple users at once. It does however lock the whole database when writing, so if you have lots of concurrent writes it is not the database you want (usually the time the database is locked is a few milliseconds — so for most uses this does not matter). But it is very well tested and very stable (and widely used) so you can trust it.

Может еще чего-нибудь хочется? Ну там изолированных транзакций из коробки?

Здравствуйте, gyraboo, Вы писали:

M>>Каких-то особых требований нет, и я бы наверное предпочёл SQLite, но он вроде не даёт одновременного доступа к одной БД из разных процессов. Хочется что-то такое же легко, не требующее отдельной установки, чтобы можно было с собой и базу и движок таскать, но позволяющее шарить БД между процессами

G>А если коннекшн закрывать после запроса?

Да можно, но кто гарантирует, что несколько процессов не захотят одновременно что-то записать? Или SQLite содержит защиту от этого, как-то лочит файл базы? Мне почему-то казалось, что там и такого нет

Здравствуйте, Dym On, Вы писали:

M>>Каких-то особых требований нет,
DO>Раз требований нет, бери любую

M>>Хочется что-то такое же легко, не требующее отдельной установки, чтобы можно было с собой и базу и движок таскать, но позволяющее шарить БД между процессами
DO>Ну и бери SQLite, вот тут пишут
DO>

DO>Yes SQLite can support multiple users at once. It does however lock the whole database when writing, so if you have lots of concurrent writes it is not the database you want (usually the time the database is locked is a few milliseconds — so for most uses this does not matter). But it is very well tested and very stable (and widely used) so you can trust it.

Хм, вполне норм. А что будет, интересно, если одновременно есть писатель и читатели?

DO>Может еще чего-нибудь хочется? Ну там изолированных транзакций из коробки?

Да не

Здравствуйте, Marty, Вы писали:

M>Хм, вполне норм. А что будет, интересно, если одновременно есть писатель и читатели?
Надо смотреть. Я лично опыта не имел. В принципе можно прикрутить какую-нибудь приблуду, типа диспетчер запросов, через которую лазать непосредственно в базу. Ну или поискать, может уже кто-то прикрутил

Здравствуйте, Dym On, Вы писали:

M>>Хм, вполне норм. А что будет, интересно, если одновременно есть писатель и читатели?
DO>Надо смотреть. Я лично опыта не имел. В принципе можно прикрутить какую-нибудь приблуду, типа диспетчер запросов, через которую лазать непосредственно в базу. Ну или поискать, может уже кто-то прикрутил

Так этот диспечер надо наверно выносить в отдельный процесс? Опять геммор

Здравствуйте, Marty, Вы писали:

M>Здравствуйте, gyraboo, Вы писали:

M>>>Каких-то особых требований нет, и я бы наверное предпочёл SQLite, но он вроде не даёт одновременного доступа к одной БД из разных процессов. Хочется что-то такое же легко, не требующее отдельной установки, чтобы можно было с собой и базу и движок таскать, но позволяющее шарить БД между процессами

G>>А если коннекшн закрывать после запроса?

M>Да можно, но кто гарантирует, что несколько процессов не захотят одновременно что-то записать? Или SQLite содержит защиту от этого, как-то лочит файл базы? Мне почему-то казалось, что там и такого нет

Движок лочит файл бд на время коннешна, поэтому второй процесс не сможет подключиться и можно сделать чтобы он ожидал освобождения файла.
И ещё, на всякий случай, делай составные запросы в транзакциях, чтобы избежать неконсистентности.

Здравствуйте, gyraboo, Вы писали:

G>Движок лочит файл бд на время коннешна, поэтому второй процесс не сможет подключиться и можно сделать чтобы он ожидал освобождения файла.
G>И ещё, на всякий случай, делай составные запросы в транзакциях, чтобы избежать неконсистентности.

Вроде бы блокировка на запись настраивается. Либо ключами, либо самому с директивами пересобрать. Либо делать отдельный процесс для бд.

Здравствуйте, vsb, Вы писали:

vsb>PostgreSQL

Кстати, хорошая СУБД (и кроссплатформенная при этом).
Не требуется покупки — т.к. это open source приложение.

Уже полтора года как мы применяем в своих проектах.

Здравствуйте, Marty, Вы писали:

M>Здравствуйте!
если java, то
https://www.h2database.com/html/main.html

Здравствуйте, varenikAA, Вы писали:

AA>если java, то
AA>https://www.h2database.com/html/main.html
На OpenJDK заведется? Или ей только Oracle нужен?

Здравствуйте, Dym On, Вы писали:

DO>Здравствуйте, varenikAA, Вы писали:

AA>>если java, то
AA>>https://www.h2database.com/html/main.html
DO>На OpenJDK заведется? Или ей только Oracle нужен?

Кончено, это же не дотнэт)))

Здравствуйте, Marty, Вы писали:

M>Хм, вполне норм. А что будет, интересно, если одновременно есть писатель и читатели?
писатели читателям не мешают (если WAL режим). может быть одновременно много читателей, они другу другу тоже не мешают.
чтоб упереться в эксклюзивную запись, это надо достаточно высокую нагрузку иметь.
у меня в продакшине используется, на 300 юзеров на одной базе, более 5лет, 30Гб база. проблем нет.

Здравствуйте, Sharov, Вы писали:

G>>Движок лочит файл бд на время коннешна, поэтому второй процесс не сможет подключиться и можно сделать чтобы он ожидал освобождения файла.
G>>И ещё, на всякий случай, делай составные запросы в транзакциях, чтобы избежать неконсистентности.

S>Вроде бы блокировка на запись настраивается. Либо ключами, либо самому с директивами пересобрать. Либо делать отдельный процесс для бд.

Ну да.
А ещё у неё есть шифрование (правда тоже нужна пересборка).
В итоге выходит, что найти альтернативу будет очень тяжело.
Я для всех своих шароварных проектов именно её использую.
Хотя один раз работал в проекте десктопного приложения, который Postgres использует, и это сделано прозрачно для юзера — т.е. никаких запусков серверов, всё скрыто от юзера. В этом плане постгрес конечно круче sqlite по многим параметрам.

Здравствуйте, vsb, Вы писали:

vsb>PostgreSQL

Странно, человек раздумывает об inproc бд, а ты ему навороченную бд в клиент серверной архитектуре предлагаешь.

Здравствуйте, white_znake, Вы писали:

vsb>>PostgreSQL

_>Странно, человек раздумывает об inproc бд, а ты ему навороченную бд в клиент серверной архитектуре предлагаешь.

Вообще-то я написал, что найти альтернативу sqlite трудно.

Про постгрес упомянул просто как ремарка на полях, т.к. работал в проекте, где постгрес был интегрирован с программой совершенно бесшовно и без всей тяжести клиент-серверной архитектуры — запуск серверов, проброс портов докера и прочих телодвижений. Причем у программы есть и десктопная версия, и мобильные сборки для андроида и ios. И какого-то клиент-серверного оверхеда я не наблюдал — всё работало очень шустро, запуск программы — буквально за пару секунд. Рекомендовать такой подход не стану, т.к. не знаю всех деталей реализации, возможно там есть какие-то ноу-хау.

Здравствуйте, Marty, Вы писали:

M>Каких-то особых требований нет, и я бы наверное предпочёл SQLite, но он вроде не даёт одновременного доступа к одной БД из разных процессов. Хочется что-то такое же легко, не требующее отдельной установки, чтобы можно было с собой и базу и движок таскать, но позволяющее шарить БД между процессами

Под твоё описание идеально подходит Firebird Embedded. Полноценный SQL-сервер. В редакции Embedded устанавливается файловым копированием.

Здравствуйте, gyraboo, Вы писали:

G>Здравствуйте, white_znake, Вы писали:

vsb>>>PostgreSQL

_>>Странно, человек раздумывает об inproc бд, а ты ему навороченную бд в клиент серверной архитектуре предлагаешь.

G>Вообще-то я написал, что найти альтернативу sqlite трудно.

G>Про постгрес упомянул просто как ремарка на полях, т.к. работал в проекте, где постгрес был интегрирован с программой совершенно бесшовно и без всей тяжести клиент-серверной архитектуры — запуск серверов, проброс портов докера и прочих телодвижений. Причем у программы есть и десктопная версия, и мобильные сборки для андроида и ios. И какого-то клиент-серверного оверхеда я не наблюдал — всё работало очень шустро, запуск программы — буквально за пару секунд. Рекомендовать такой подход не стану, т.к. не знаю всех деталей реализации, возможно там есть какие-то ноу-хау. Зато возможности для программы открывались широкие — при необходимости можно было подключаться к удаленному бд серверу совершенно так же, как к локальному (естественно, что в терминах программы фигурировал не БД-сервер, а "хранилище данных"). С sqlite так просто удаленный доступ не организовать.

Здравствуйте, Marty, Вы писали:

DO>>Надо смотреть. Я лично опыта не имел. В принципе можно прикрутить какую-нибудь приблуду, типа диспетчер запросов, через которую лазать непосредственно в базу. Ну или поискать, может уже кто-то прикрутил

M>Так этот диспечер надо наверно выносить в отдельный процесс? Опять геммор

Зачем? Весь такой диспечер делается на одном именованном мьютексе.

Здравствуйте, IT, Вы писали:

IT>Зачем? Весь такой диспечер делается на одном именованном мьютексе.

Да, да, а потом придумывать что с ним таким прекрасным делать, если приложение упало без раскрутки стека. Был у нас такой один прекрасный диспечер

Здравствуйте, kaa.python, Вы писали:

KP>Да, да, а потом придумывать что с ним таким прекрасным делать, если приложение упало без раскрутки стека. Был у нас такой один прекрасный диспечер

Ну дык мало ли чего вы там ещё накрутили. У нас такая простейшая синхронизация процессов работает уже много лет шо железная железяка. Каждый день без выходных.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Marty, Вы писали:
IT>Зачем? Весь такой диспечер делается на одном именованном мьютексе.

Здравая идея. А что будет, если процесс во время удержания помрет?

Здравствуйте, IT, Вы писали:

DO>>>Надо смотреть. Я лично опыта не имел. В принципе можно прикрутить какую-нибудь приблуду, типа диспетчер запросов, через которую лазать непосредственно в базу. Ну или поискать, может уже кто-то прикрутил

M>>Так этот диспечер надо наверно выносить в отдельный процесс? Опять геммор

IT>Зачем? Весь такой диспечер делается на одном именованном мьютексе.

А можно раскрыть мысль?

Здравствуйте, Sharov, Вы писали:

IT>>Зачем? Весь такой диспечер делается на одном именованном мьютексе.
S>Здравая идея. А что будет, если процесс во время удержания помрет?

Одному из оставшихся будет дан зелёный свет.

Здравствуйте, IT, Вы писали:

IT>Одному из оставшихся будет дан зелёный свет.

А мьютекс разве не будет сдержан навсегда упавших процессом? Хотя ОС это должна понять и освободить соотв. ресурс. Скорее всего проблем не будет и вариант нормальный.

Здравствуйте, Marty, Вы писали:

M>А можно раскрыть мысль?

public class MutexLock : IDisposable
{
    Mutex _mutex;

    public MutexLock(string name)
    {
        while (true)
        {
            _mutex = new Mutex(false, name);

            try
            {
                _mutex.WaitOne();
            }
            catch (AbandoneMutexException ex)
            {
                Thread.Sleep(1000 * 3)
                continue;
            }

            break;
        }
    }

    public void Dispose()
    {
        _mutext?.ReleaseMutex();
        _mutext?.Dispose();
    }
}

Использование

using (new MutexLock("MyDbAccess"))
{
    // access to my db
}

Здравствуйте, Sharov, Вы писали:

S>А мьютекс разве не будет сдержан навсегда упавших процессом? Хотя ОС это должна понять и освободить соотв. ресурс. Скорее всего проблем не будет и вариант нормальный.

С этим проблем вроде не было. Бывает исключение типа AbandoneMutexException при создании, но это решается в примере выше.

Здравствуйте, IT, Вы писали:

M>>А можно раскрыть мысль?

IT>

IT>public class MutexLock : IDisposable
IT>

Что-то громковато лок на мьютексе ты назвал диспетчером запросов

ЗЫ Да, я обновил свои хотелки — забыл сразу указать, что мне нужна джаба и C++ (под винду, но тем не менее. блин, про подвинду тоже забыл указать

)

Здравствуйте, Marty, Вы писали:

M>Что-то громковато лок на мьютексе ты назвал диспетчером запросов

Это не я. Я-то как раз сразу сказал, что диспетчеров никаких не надо.

M>ЗЫ Да, я обновил свои хотелки — забыл сразу указать, что мне нужна джаба и C++ (под винду, но тем не менее. блин, про подвинду тоже забыл указать

)

Ну дык там логика должна быть понятна даже джабо/C++ неудачникам

Здравствуйте, Marty, Вы писали:

M>ЗЫ Да, я обновил свои хотелки — забыл сразу указать, что мне нужна джаба и C++ (под винду, но тем не менее. блин, про подвинду тоже забыл указать

)

Так мьютекс это примитив ОС,язык тут не при чем.

Здравствуйте, IT, Вы писали:

M>>Что-то громковато лок на мьютексе ты назвал диспетчером запросов

IT>Это не я. Я-то как раз сразу сказал, что диспетчеров никаких не надо.

IT>Зачем? Весь такой диспечер делается на одном именованном мьютексе.

Мог бы и кавычки поставить тогда

M>>ЗЫ Да, я обновил свои хотелки — забыл сразу указать, что мне нужна джаба и C++ (под винду, но тем не менее. блин, про подвинду тоже забыл указать

)

IT>Ну дык там логика должна быть понятна даже джабо/C++ неудачникам

Просто хз, как из джабы до виндовых мутексов доковыривать

Здравствуйте, Marty, Вы писали:

M>Просто хз, как из джабы до виндовых мутексов доковыривать

https://www.google.com/search?q=java+windows+named+mutex&rlz=1C1CHBF_enUS907US907&oq=java+windows+named+mutex&aqs=chrome..69i57j33i22i29i30.9751j0j7&sourceid=chrome&ie=UTF-8

Здравствуйте, vsb, Вы писали:

vsb>PostgreSQL

Тогда уж Oracle Portable Edition

Здравствуйте, Sharov, Вы писали:

M>>ЗЫ Да, я обновил свои хотелки — забыл сразу указать, что мне нужна джаба и C++ (под винду, но тем не менее. блин, про подвинду тоже забыл указать

)

S>Так мьютекс это примитив ОС,язык тут не при чем.

В плюсиках просто системные (виндовые) либы подключаются, а как в джабе, я хз. Она же вся из себя кроссплатформенная, а АПИ для мьютексов в кажой ОС своё

)
Кстати сишный пример есть прямо в MSDN: https://docs.microsoft.com/en-us/windows/win32/sync/using-mutex-objects

Здравствуйте, white_znake, Вы писали:

vsb>>PostgreSQL

_>Странно, человек раздумывает об inproc бд, а ты ему навороченную бд в клиент серверной архитектуре предлагаешь.

Вроде люди делают PostgreSQL embedded. То, что он навороченный, не значит, что он плохой. Ну и вообще моё дело вариант добавить, решать топикстартеру. Я бы тоже SQLite взял ) Или вообще какую-нибудь жабью БД вроде H2. Но советовать не буду, опыта с ней нет.

Здравствуйте, Dym On, Вы писали:

M>>ЗЫ Да, я обновил свои хотелки — забыл сразу указать, что мне нужна джаба и C++ (под винду, но тем не менее. блин, про подвинду тоже забыл указать

)
DO>Кстати сишный пример есть прямо в MSDN: https://docs.microsoft.com/en-us/windows/win32/sync/using-mutex-objects

Ну, мьютексом я пользовался, да. Тока мьютекс — это не диспетчер доступа к БД, а в данном случае просто костыль

Здравствуйте, Marty, Вы писали:

M>Ну, мьютексом я пользовался, да. Тока мьютекс — это не диспетчер доступа к БД, а в данном случае просто костыль
Ну тут опять же вопрос требований, если достаточно костыля, почему бы и нет.

PS Но постепенно уже формируется некоторое ТЗ

Здравствуйте, Dym On, Вы писали:

M>>Ну, мьютексом я пользовался, да. Тока мьютекс — это не диспетчер доступа к БД, а в данном случае просто костыль
DO>Ну тут опять же вопрос требований, если достаточно костыля, почему бы и нет.

DO>PS Но постепенно уже формируется некоторое ТЗ

Ага, да

Нужен SQL, без изысков — норм
Доступ из джава и C++ — какие-то удобные либы и там и там нужны.
Win32
Что-то безсерверное, inproc.
Один пишет много, другие читают много. Читатели редко-редко что-то записывают, писатель периодически почитывает некоторые таблицы — ищет отзывы от читателей
Носить на ~~дискетке~~флешке рабочую копию

Здравствуйте, IT, Вы писали:

IT>Ну дык мало ли чего вы там ещё накрутили. У нас такая простейшая синхронизация процессов работает уже много лет шо железная железяка. Каждый день без выходных.

В управляемой среде проблемы нет, т.к. приложение не может (почти никогда) аварийно завершиться. Приложение на C++ может, и иногда так и делает. В результате у тебя нет раскрутки стека, и просто никто не отдает мутекс системе после падения как минимум в POSIX. Лечится по старинке перезагрузкой компьютера!

Здравствуйте, Marty, Вы писали:

M>Нужен SQL, без изысков — норм
M>Доступ из джава и C++ — какие-то удобные либы и там и там нужны.

H2 вроде совместима с клиентом postgres (не точно).

S>Под твоё описание идеально подходит Firebird Embedded.

Выделяю болдом фрагмент в его описании:

Хочется что-то такое же легко, не требующее отдельной установки, чтобы можно было с собой и базу и движок таскать, но позволяющее шарить БД между процессами

Теперь смотрим на описание предложенного тобой, тоже на всякий случай болдом выделю:

only single user access

В более глубоких интернетиках находится информация о возможности использовать костыль через конкурирующее дрюканье лок-файла, но не раскрывается тема стабильности — что будет, если текущий локер примет ислам. Кроме того, данный костыль доступен и в сабжевом SQLite.
Короч, так себе альтернатива, до "идеальной" ей как раком до луны.

S>Полноценный SQL-сервер.

Здравствуйте, kaa.python, Вы писали:

IT>>Ну дык мало ли чего вы там ещё накрутили. У нас такая простейшая синхронизация процессов работает уже много лет шо железная железяка. Каждый день без выходных.

KP>В управляемой среде проблемы нет, т.к. приложение не может (почти никогда) аварийно завершиться. Приложение на C++ может, и иногда так и делает. В результате у тебя нет раскрутки стека, и просто никто не отдает мутекс системе после падения как минимум в POSIX. Лечится по старинке перезагрузкой компьютера!

У Рихтера же вроде русским по белому было написано, что мьютек (нормальный системный виндовый объект) будет освобожден, если удерживающий его поток (процесс?) завершится (полагаю, в том числе и аварийно)...

Сам я ни разу не удосужился это проверить

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>У Рихтера же вроде русским по белому было написано, что мьютек (нормальный системный виндовый объект) будет освобожден, если удерживающий его поток (процесс?) завершится (полагаю, в том числе и аварийно)...

Я такую беду на macOS ловил, что там в Windows вообще не в курсе

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	07.12.20 18:02
Оценка:

	От:	gyraboo
	Дата:	07.12.20 18:22
	Оценка:

	От:	Dym On
	Дата:	07.12.20 18:38
	Оценка:	6 (1)

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	07.12.20 18:55
Оценка:

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	07.12.20 19:01
Оценка:

От:	IT	linq2db.com
Дата:	08.12.20 14:33
Оценка:	16 (1) +1

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	08.12.20 16:10
Оценка:	+1

	От:	Аноним931
	Дата:	13.01.21 10:59
	Оценка:

От:	Коваленко Дмитрий	http://www.ibprovider.com
Дата:	19.01.21 07:08
Оценка: