https://opennet.ru/openforum/vsluhforumID3/118652.html Опубликован релиз SQLite 3.30.0, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51621<br> https://opennet.ru/openforum/vsluhforumID3/118652.html#40 Sun, 13 Oct 2019 05:45:38 GMT Предпочтительнее простенький REST API сделать, чем сетевые файловые системы использовать. Или, как вариант, работать с копиями базы локально и время от времени синхронизировать с основной базой. Все зависит от задачи.<br> https://opennet.ru/openforum/vsluhforumID3/118652.html#39 Wed, 09 Oct 2019 20:46:25 GMT Скрипт бд, запросы и свои замеры в студию.<br> https://opennet.ru/openforum/vsluhforumID3/118652.html#38 Tue, 08 Oct 2019 09:38:17 GMT Прочитаю, спасибо! Оптимизировать запросы пока нет необходимости, итак всё "летает". Таймауты ловятся редко и не парят совершенно. А WAL-режим разве работает при доступе к файлу по сети LAN? По-моему он только при чтении на той же машине работает.<br> https://opennet.ru/openforum/vsluhforumID3/118652.html#36 Mon, 07 Oct 2019 17:39:25 GMT Медленнее, но не поэтому. При доступе только на чтение без блокировок нет никаких "конфликтов записи". <br><br>&gt; "SQLite если и читает во время записи - просто шлет таймаут клиенту на 1 сек. и всё. "<br><br>Не обязательно, есть разные варианты работы. Смотрите WAL-режим, чтение "грязных" данных и проч. настройки. Так что можно и без таймаутов обходиться.<br><br>Рекомендую вот это почитать:<br>https://www.sqlite.org/queryplanner-ng.html<br>Ну и вдобавок<br>https://sqlite.org/optoverview.html<br><br>В рунете вообще не встречал обсуждений того, насколько хорош планировщик запросов эскулайт. Помнится, на форуме sql.ru Олег Бартунов на мой вопрос о возможности создания детерминированного планировщика для постгреса счел это невозможным. Хотя в эскулайте детерминированный планировщик практически полностью решает все проблемы с планами выполнения - в самых сложных случаях достаточно правильную статистику собрать/сгенерировать.<br> https://opennet.ru/openforum/vsluhforumID3/118652.html#35 Mon, 07 Oct 2019 17:27:43 GMT "в 3-4 раза быстрее" - это ерунда, потому что на сложных селектах из многих таблиц можно и на 3-4 порядка (десятичных) выигрыш получить. При условии, что статистика таблиц собрана правильно или сгенерирована (эскулайт умеет сохранить и загрузить статистику для планировщика). А вот в постресе, к примеру, объединение десятков таблиц или сложные коррелированные подзапросы требуют шаманства для получения правильного плана выполнения. Особенно, когда речь идет о пространственных данных и модулях PostGIS vs Spatialite.<br> https://opennet.ru/openforum/vsluhforumID3/118652.html#34 Mon, 07 Oct 2019 10:05:19 GMT Сеть не тормозит, один сегмент. Индексы используем обычные (аналитика бухучета по субконто - названия Контрагентов, Материалов итп). Серверные СУБД медленнее SQLite просто потому что заняты предотвращением конфликтов записи и проверкой типов. SQLite если и читает во время записи - просто шлет таймаут клиенту на 1 сек. и всё. <br> https://opennet.ru/openforum/vsluhforumID3/118652.html#33 Mon, 07 Oct 2019 08:51:04 GMT Это у вас 1GB сеть тормозит :) Ну или Btree индексы слишком активно используете...<br> https://opennet.ru/openforum/vsluhforumID3/118652.html#32 Mon, 07 Oct 2019 08:48:51 GMT Зато автор рассматривает присылаемые патчи и переписывает их сам, если удастся убедить, в чем их польза. В свое время я достаточно долго с Ричардом обсуждал добавление сжатия FTS-индекса и он это реализовал в коде - хотя и не так, как было сделано в моих патчах, но какая разница.<br> https://opennet.ru/openforum/vsluhforumID3/118652.html#31 Mon, 07 Oct 2019 05:44:17 GMT SQLite, расшаренная на десrтопе на SSD в типичном режиме работы: <br>- 1 поток записи (5% времени) <br>- 4 потока чтения по сети 1GB LAN через ODBC/JDBC (20% времени) <br>- простой (75% времени)<br>оказывается в 3-4 раза быстрее по отклику и скорости выполнения SQL-запросом чем в тех же условиях та же база на MS Access, HSQLDB, MySQL, PostgreSQL, FireBird. База 1 Гб, 100 полей х 3000000 строк <br>Работа с SQLite с WAL из Python - оказывается еще быстрее раза в два. Честно говоря, ничего быстрее я не знаю и скорее всего что быстрее ничего нет. Все дело в указателях файла. IN-MEMORY она тоже умеет, но это не в счет. <br>