SQL запрос в SQLite - страница 13
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я не сам подключаюсь к базе, а посредством FireDAC, если что-то в Марии будет не так,
то нормально работать не будет.
Для приложения обычно нет разницы, MariaDB или MySQL.
Я почитал сравнение MySQL и PostgreQSL и понятно, что в этом выборе
PostgreQSL - однозначно!
Только не забывать, что это версионник и там есть такие вещи, как вакуум и автовакуум.
Мне на одной работе приходилось отключать автовакуум на рабочее время и делать ночью некоторым таблицам принудительный vacuum full.
собственно "давно обещанное большевиками случилось" :-(
а именно файловые блокировки
Режима когда их нет - НЕТ.
Возможны некоторые обходные пути, которые могут временно помочь (именно временно, потом всё равно те-же грабли):
* перенесите базу в RAM-диск
* у вас множество хендлов к базе - разделите кому не надо писать пусть будет read-only
* отключите auto-commit, оберните все запросы в TRANSACTION, а COMMIT/ROLLBACK вызывайте самостоятельно и обрабатывайте ошибки (повторы, переподключения, etc)
* как самый крайний случай добавьте RW-Mutex ко всем запросам. Это убьёт скорость напрочь (всё равно что однопоточно), но зато блокировки будут на уровень выше и не вызовут краха.
а вообще надо смотреть на другие базы пока не поздно.
из встраиваемых в приложения (не требующих отдельного сервера) и более менее близких с SQLite есть:
* monetdb/e https://www.monetdb.org/ - сильно быстрее SQLite, но в многопотоке не пробовал.
* FireBird https://firebirdsql.org/ - традиционно любимая бухгалтерами :-)
или брать знакомое зло в виде Postgresql , MySQL
Я бы взял конечно MSSQL
могу поделиться самой свежей от 2022 - с ключикомДля приложения обычно нет разницы, MariaDB или MySQL.
Только не забывать, что это версионник и там есть такие вещи, как вакуум и автовакуум.
Мне на одной работе приходилось отключать автовакуум на рабочее время и делать ночью некоторым таблицам принудительный vacuum full.
я бы предложил MSSQL
Я не сам подключаюсь к базе, а посредством FireDAC, если что-то в Марии будет не так,
то нормально работать не будет.
Я почитал сравнение MySQL и PostgreQSL и понятно, что в этом выборе
PostgreQSL - однозначно!
Добавлено
Я выбрал SQLite по нескольким причинам:
1. Она есть в списке FireDAC
2. Достаточно быстрая
3. Простая в "разворачивании"
4. Программа для Плаза 2 должна проходить сертификацию
и "танцы с бубном" им (проверяющим) совсем не нужныПочитайте разницу между MS SQL и PostgreQSL
недавно переносил не очень большую базу порядка 100 ггб из PostgreQSL в MSSQL
Скорость выросла , еще пока были на PostgreQSL - часто случались "метрвые объятия" блокировки - после перехода на MS SQL ушло как явление.
Ну это как перейти с жигули на мерседес.
Почитайте разницу между MS SQL и PostgreQSL
недавно переносил не очень большую базу порядка 100 ггб из PostgreQSL в MSSQL
Скорость выросла , еще пока были на PostgreQSL - часто случались "метрвые объятия" блокировки - после перехода на MS SQL ушло как явление.
Ну это как перейти с жигули на мерседес.
Сдаётся мне, вы его неправильно готовили.
Сдаётся мне, вы его неправильно готовили.
До просто обычная практика , по которой MSSQL в реальности дал лучший результат.
Берем две базы полностью одинаковые , на одном и том же железе, и пробуем добиться лучших результатов на PostgreQSL и MSSQL , перебирая изучая меняя все настройки.
При всех равных услових в железе , MSSQL дал лушие результаты в скорости. Еще подчеркиваю ( не я писал часть кода который вызывал Deadlock , вопрос конечно тонкий искать подобные фишки ) но после перехода на MSSQL ушли ко всему прочему и Deadlock.
для начала сравним совсем отвлеченную фишку делаем backup 100 ггб базу ( подчеркиваю на одном и том же железе )
1) PostgreSQL , на удивление 2 часа.
2) MSSQL , идет полторы минуты.
Но это так , мелочи в срвнении с остальными плюшками.
Кстати 4 тб базу не пробовали бэкапить на PostgreSQL , а на MSSQL ?
Но сравнивать конечно лучше на запросах , например из таблицы в два миллирда записей.
дополню - разные мелочи от практиков
запустил замер производительности, в постри работает тормознее..
постри:
запись документов 132,73 сек. 41%
удаление 95,22 сек. 30%
мс скл:
запись 82,2 сек. 36%
удаление 78,6 сек. 35%
https://habr.com/ru/articles/457602/
Еще немного о разнице между жигулями и мерседесом.
...ключевые выжимкм из статьи
в общем синтетическом тесте СУБД PostgreSQL проиграла по производительности СУБД MS SQL в среднем на 14,82%.
Исходя из этого, можно сделать более вероятное предположение, что 1С версии 8.3 и новее можно перенести с MS SQL на PostgreSQL с максимальной потерей производительности до 15%.
тут правда версия MSSQL староенькая 13.0.5264.1 - интересно что поазала бы 16-я
Будете утвержать и далее , типа спецы которые проводили тесты не умеют "готовить кошек" :-) ?
https://habr.com/ru/articles/457602/
Еще немного о разнице между жигулями и мерседесом.
...ключевые выжимкм из статьи
в общем синтетическом тесте СУБД PostgreSQL проиграла по производительности СУБД MS SQL в среднем на 14,82%.
Исходя из этого, можно сделать более вероятное предположение, что 1С версии 8.3 и новее можно перенести с MS SQL на PostgreSQL с максимальной потерей производительности до 15%.
тут правда версия MSSQL староенькая 13.0.5264.1 - интересно что поазала бы 16-я
Будете утвержать и далее , типа спецы которые проводили тесты не умеют "готовить кошек" :-) ?
в целом, при работе с 1С
MSSQL рвёт Postress как тузик грелку.
Иных баз которые таскают то в Pg то в Ms просто не существует..
А есть ещё Oracle, который умеет трепать обоих их :-)
Но ТС хочет базу не накладывающую ограничений (или доп.роялти) на потенциальных пользователей. Поэтому MSSQL пролетает
в целом, при работе с 1С
MSSQL рвёт Postress как тузик грелку.
Иных баз которые таскают то в Pg то в Ms просто не существует..
А есть ещё Oracle, который умеет трепать обоих их :-)
Но ТС хочет базу не накладывающую ограничений (или доп.роялти) на потенциальных пользователей. Поэтому MSSQL пролетает