https://mobile.opennet.me/openforum/vsluhforumID3/111305.html Представлен (http://www.mail-archive.com/sqlite-announce@sqlite.org/msg00066.html) релиз SQLite 3.19.0 (http://sqlite.org/), легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg. <br><br><br>Большинство изменений в новой версии связаны с проведением (http://sqlite.org/releaselog/3_19_0.html) модернизации планировщика запросов, которая позволила заметно поднять производительность сложных запросов. Оптимизировано использование индексов - если в индексе присутствует значение, фигурирующее в выражении, то теперь используется значение из индекса, вместо загрузки оригинального значения столбца и повторного вычисления выражения.<br><br>Оптимизирована обработка представлений в левой части выражений "LEFT JOIN". https://mobile.opennet.me/openforum/vsluhforumID3/111305.html#36 Mon, 29 May 2017 10:47:49 GMT ага, спасибо, идея понятна- то есть все делать самому, "я лучше какой-то паршивой тазы банных знаю, что и куда мне бэкапать". В принципе, оно, конечно, и правильно...<br> https://mobile.opennet.me/openforum/vsluhforumID3/111305.html#35 Fri, 26 May 2017 17:48:20 GMT Целый и работоспособный файл базы плюс бэкап - отнюдь не гарантируют, что данные там валидны :) На мой взгляд, бэкап должен быть уровнем выше - не данных в базе, а тех данных, что в базу поступают. Когда-то делал коммит хук в процессинге с эскулайт, чтобы логировать, сейчас данные практически всегда заливаю пакетно (хоть раз в секунду, но пакетом), так что эти данные и нужно сохранять вне хоста с базой - тогда легко развернуть тестовые инстансы и проч. Вот гораздо вероятнее в своей системе огрести какую-то ошибку обработки данных (для исправления которой надо данные обработать заново или как минимум их проанализировать), нежели словить критическую ошибку типа потери диска на AWS EC2 к примеру. Ну и раз в час/сутки/неделю/месяц (по потребностям) выгружать важные таблицы (скажем, данные абонентов и баланс если это биллинг) в формате пригодном для использования diff и уже в таком виде хранить. А в самой базе для важных таблиц можно делать только неизменяемые записи (то есть версионирование) - последняя версия за https://mobile.opennet.me/openforum/vsluhforumID3/111305.html#34 Fri, 26 May 2017 13:13:08 GMT &gt; Как только начинается конкурентная запись в сколько-нибуль заметных масштабах.<br><br>"Более другие" СУБД объединяют данные, записанные пакетно, с данными из памяти, которые будут пакетно записаны позже, плюс ведут журнал восстановления и проч. И вся конкурентность сериализуется для записи. Так что связка редис (данные в памяти) и эскулайт (пакетно записанные на диск) на порядки превосходит те же постгрес, оракл (кажется, некоторые считают, что мускуль тоже субд, ну да их право) по скорости работы, но для несохраненных данных (в редис) мы должны отдельно обработку писать, что не так удобно. А вот скажем, биллинг на десятки-сотни гигабайт сырых данных в месяц элементарно делается - потому что обработка несохраненных данных не нужна, а для сохраненных в эскулайт делается элементарно (расширение для процессинга ipv4 адресов в эскулайт я давно как выкладывал, во многих проектах используется, для телефонных не добрался выложить, т.к. там слишком много зависимостей), и работает очень быстро.<br> https://mobile.opennet.me/openforum/vsluhforumID3/111305.html#33 Fri, 26 May 2017 13:04:28 GMT Бэкап в реалтайме никак не выглядит - нет его, так как времени на его восстановление просто не будет. Раз в N секунд данные сбрасываются из редис в активную минутную базу, раз в минуту создается новая минутная база, раз в 6 минут - шестиминутная и раз в час - часовая. При выборке вычисляется необходимый временной интервал и аттачится набор нужных баз для покрытия этого интервала. Подавляющее количество запросов как раз хотят данных за последнюю минуту. Так что нужны два (или более) независимых хоста процессинга, при дописывании минутных баз просто транзакции использованы - если сейчас запись не удалась, через вышеуказанные N секунд будут дописаны все отсутствующие данные. Собственно, главная хитрость в том, что индексы FTS для пространственных данных использованы - иначе при любых других (из spatialite, r-tree, не говоря уже о стандартном b-tree) такой поток данных просто не записать в базу (ибо нет компрессии ключа и использовано одно индексное дерево, тогда как в FTS - мультидерево). Ну как раз с индексами https://mobile.opennet.me/openforum/vsluhforumID3/111305.html#32 Fri, 26 May 2017 11:17:29 GMT &gt; Так что, бэкап zfs/llvm/etc снапшотом вполне валиден<br><br>ну, я в общем интересовался, как оно у других (из тех кто, разумеется, понимает, что можно, а что нельзя) - вдруг есть более интересные ходы, до которых я не додумал.<br><br>wal я, кстати, использую с normal - мну тут не деньги считает...э...ну в общем все равно не свои, последнюю транзакцию в общем-то ни разу не жаль (но, разумеется, это еще одна причина никогда так не делать, если не ты разработчик или если он не за соседним столом)<br><br> https://mobile.opennet.me/openforum/vsluhforumID3/111305.html#31 Fri, 26 May 2017 05:27:17 GMT Недописанная транзакция - не проблема для sqlite3 . Исследования показали, что из всех баз с открытым кодом, sqlite3 наиболее параноидально работает с диском. Так что, пока диск не посыпался, данные будут в порядке.<br>Есть только 1 момент с завершением транзакции и undo логом (старый режим). Если использовать WAL (новый режим), то проблем нет.<br>Так что, бэкап zfs/llvm/etc снапшотом вполне валиден - он не отличим от "выдернули кабель питания", а с эти sqlite3 спраляется.<br> https://mobile.opennet.me/openforum/vsluhforumID3/111305.html#30 Thu, 25 May 2017 11:09:13 GMT ты лучше расскажи, как у тебя бэкап этого монстра выглядит? Или там что-нибудь вроде "zfs snap и пусть sqlite как-нибудь сама разбирается потом, что делать с недописанной транзакцией" (благо ни ora0006, ни "поднимите мне индексы" у нее не бывает)?<br><br> https://mobile.opennet.me/openforum/vsluhforumID3/111305.html#29 Thu, 25 May 2017 09:25:23 GMT По скорости сложных выборок - эскулайт на порядки опережает постгрес. При использовании эсулайт в паре с редисом - и миллион пользователей на чтение-запись в реалтайме не проблема на простеньком серваке. При этом я работаю с пространственными запросами, так что большинство остальных задач намного примитивнее. И да, постгрес, оракл и проч. такое количество скажем навигационных данных не переварят (миллион машинок с интервалом обновления 10 секунд - это 100 000 записей в секунду, где нужно фильтрацию сделать для очистки от недостоверных значений, найти ближайшие сегменты OSM и проч.). Впрочем, в россии таких задач просто нет, так что вам выгоднее знать оракл :) Знакомые, кого приглашали в тот же яндекс навигацией заниматься - рассказывали, насколько там неестественно СУБД насилуют для обработки пространственных данных. В 2gis, судя по статьям на хабре, аналогичная ситуация. Так что в совке на эскулайт можно и нужно, но не надо :D<br> https://mobile.opennet.me/openforum/vsluhforumID3/111305.html#28 Thu, 25 May 2017 07:28:39 GMT &gt; А если только читают?<br><br>тоже могут дырку в диске прогрызть, увы (если база немаленькая и не простая). <br>а для fine-tuning опять же нужно чтобы не ты, а автор кода заморачивался спецификой именно этой среды, а не "понаоптимизировал" все в мечтах что "все базы больше тестовой будут psql" (тот-то как-нибудь пережует результаты этой "оптимизации", которая редко бывает хорошей и еще реже - остается правильной и через пару лет)<br><br><br>