Комментарии 89
Бар проще посчитать через оконные функции, что-то вроде
select count(*) over (partition by slot) / count(*) over ()
Мне тоже кажется, что 10000 — это художественное преувеличение ツ Вообще, если без экстрима, этих двух настроек должно быть достаточно:
pragma journal_mode = WAL;
pragma synchronous = normal;
Мне тоже кажется, что 10000 — это художественное преувеличениеСкорее всего, это если сравнивать самый худший и самый лучший вариант. Где самый худший — это добавления тысяч строк по одной без использования транзакций, при настройках на самом надежном и медленном режиме.
Есть несколько видов sqlite-dict, которые умеют только делать таблицу в 2 колонки и представлять её как словарь — но зачастую большего и не нужно.Естественно. И это для 95% задач хватает даже с избытком. Однако же тогда зачем этот скюлайт-словарь?)) Обычных программных словарей опять же хватает для таких задач. Автор там где-то пишет, что почитал он или что-то вписал куда-то и у него оно АЖ 240тыщ вроде записей в секунду составило. Извините, но заполнение/чтение/вставки в программные словари — это миллионы «записей» в секунду, обычное дело. Я про то что программные штатные средства работают на порядок быстрее (даже в шарпе).
п.с.: Как бы я не использовал все эти бд даже узкозаточенные — один фиг всегда перехожу на самописный код, ибо да, оно как минимум на порядок быстрее работает, чудес не бывает.
п.п.с.: Понятное дело что самописное годится не всем и не всегда, но тем не менее как оно и было написано кем то тут — все эти бд — это игрушки…
Спасибо тебе, добрый человек!
sqlitedict прямо то, что доктор прописал, похоже, для своих проектов самое оно (и не только).
Плюс еще там можно и запросы выполнять, а учитывая нативную поддержку json, все вообще замечательно :)
Я в основном использую SQLite для прикладного анализа данных. Загрузить датасет из csv / json, найти проблемы в данных, почистить данные, сджойнить таблички, пофильтровать, сгруппировать, посчитать агрегаты, выгрузить обратно в csv — как-то так.
Удобно, что в большинстве случаев не приходится даже ничего писать на Python. SQL, как декларативный язык, созданный специально для обработки данных — компактнее и проще, чем скрипты.
Еще использую SQLite как базу для блога. Работает быстро, удобный бекап — закоммитил один файл в гитхаб и готово.
Интересное использование, спасибо за статью. Не знал о такой возможности.
У меня периодически возникает такая необходимость, я обычно открываю CSV в экселе-там тоже очень удобно делать фильтры, группировки, аггрегаты, но попробовал бы вариаинт с SQL
Эксель прекрасный инструмент, ни в коем случае не хочу как-то его принизить. Но вот нормально работать в нем с несколькими связанными таблицами — совсем не получается.
В целом, «SQLite против Excel» чем-то схоже с «командная строка против проводника». Безусловно, сложнее. Но если освоить — удобнее, мощнее и продуктивнее для большого класса задач.
Я бы еще поспорил кто сложнее, по-моему excel это та бездна которую до конца изучить невозможно.
Я как раз хочу попробовать решение автора потому что SQL сам по себе проще и более знаком мне, а в экселе слоожные сценарии мне надо либо гуглить либо обходится тем что знаю и делать больше руками.
Например я сходу не помню как легко аггрегировать данные с нескольких листов, хотя и видел это.
Я разбивал джсон на колонки, делал поиск по вложенным полям-но сейчас хоть убей не вспомню как-если понадобится буду опять гуглить.
Для меня Power Query — это еще один навороченный доменный язык для работы с данными. Осваивать его совершенно не хочется, потому для работы с данными уже придумали SQL, который поддерживается всеми современными СУБД.
Визуально, конечно Power Query круче консоли SQLite. Но если вместо консоли использовать Apache Superset или Metabase — получится еще круче.
Плюсы будут когда количество строк будет ближе к 10 млн и потребует очень большого числа джоинов. В остальных случаях плюсов скорее всего не будет. Но все зависит от ситуации и потребности.
Здравствуйте. А можно подробнее про решение для блога? Это какой-то движок для блогов или статический генератор сайтов? И что именно коммитится? Некий патч в бд, маркдаун статьи или что-то третье? Вообщем, интересна и эта прикладная часть использования СУБД! Заранее спасибо за ответ.
Используем LiteDB в своём проекте уже несколько лет (около 15 тыс установок у клиентов, довольно небольшая нагрузка, порядка 1 rps вида «прочитать состояние из бд, внести изменения, сохранить назад обновлённую версию», размер базы порядка 10-100мб).
Мигрировали с LocalDb, во время миграции сравнивали с SQLite по производительности/удобству.
Основной плюс — работает очень быстро. Как мы не тюнили SQLite — litedb из коробки обгонял его по нашему workflow работы (без изменения основной логики приложения) в разы. Оба они на порядок обгоняли localdb.
Главный минус — я бы не назвал litedb production-ready. Периодически всплывают баги, приводящие к нарушению структуры базы и делающие её нечитаемой. Уже по-моему третья «мажорная» версия вышла которая обещает что вот теперь то мы их все исправили, но на нашей клиентской Бахе все равно раз в пару месяцев у кого-нибудь что-то ломается. В другом use-case где мы используем её чисто как кеш (под достаточно объемные данные часто изменяющиеся) — у неё течёт размер и раз в несколько месяцев приходится руками сносить Файлы, потому что размер бд вырастает до десятка Гб.
Своя структура работы, нет поддержки популярными Orm, нет транзакций (по крайней мере когда мы её выбирали, потом их добавили, потом отказались, в общем политика меняется от версии к версии).
В целом — для собирания Proof of concept проекта с последующей переделкой, или под данные которые если что не жалко потерять или можно восстановить из других источников — очень удобно. Настраивается быстро, работа интуитивная, все летает. Но как полноценную единствннную БД в серьезном проекте — я бы не стал использовать.
Embedded NoSQL database for .NET
An open source MongoDB-like database with zero configuration — mobile ready
по-моему описание с www.litedb.org/ говорит само за себя.
Из плюсов — доступно в исходниках.
Частенько использую sqlite для in-memory хранилища, когда нужно делать множественные выборки данных по нескольким полям.
Рассказываю, почему игрушка (для кто не в курске):
bash-5.1$ sqlite3 test.sqlite
-- Loading resources from /Users/justhabrausr/.sqliterc
SQLite version 3.28.0 2019-04-15 14:49:49
Enter ".help" for usage hints.
sqlite> CREATE TABLE abc (icol INTEGER);
sqlite> INSERT INTO abc (icol) VALUES ("tratata");
sqlite> SELECT * FROM abc;
tratata
sqlite> .quit
bash-5.1$
Так что не всё то лапочка, что солнышко.
Я, видимо, что-то пропустил.
Покажите как одной строчкой C записать напрямую в память невзирая на тип данных.
Без предупреждений компилятора и runtime error. Как в примере с SQLite.
PS. это не к тому, чтобы сравнивать С и SQLite (занятие довольно бестолковое непрактичное), а чисто по-женски интересно стало.
- man memcpy: "Функция memcpy() копирует n байтов..." (AKA uint8_t).
- В постановке задачи — не "с приведением к void", а "невзирая".
"Не прокатило..." ©
байт в данном случае выступает как минимальная единица длины данных, а не как тип данных. SQLite тоже не позволяет мне 3 бита в память записать.
П.С. байт это не обязательно 8 бит, поэтому, если упарываться дальше, то можно вводить и всякое типа uint7_t =)
Да, в плане типов SQLite — это своеобразный JavaScript. Если для кого-то это проблема, можно просто не использовать такую «динамическую типизацию». Используйте The Good Parts ツ
А начиная с версии 3.37 типы полей и вовсе не проблема, потому что можно использовать STRICT-таблицы.
С удивлением (на самом деле нет, когда не читаешь всю документацию так бывает) узнал кучу нового, и про динамическую типизацию из комментов, и про with recursive,…
Хабр торт.
Можно даже обращаться к ней из нескольких соединений:К сожалению только в пределах одного процесса, т.е. shared не имеет особого смысла и сомнительный юзкейс
db = sqlite3.connect(«file::memory:?cache=shared»)
Мне особенно нравится, что последние годы разработчики SQLite часто сознательно реализуют фичи точно так же, как сделано в PostgreSQL. Например, оконные функции сделаны именно так, и даже тестировались на постгресе. Кажется, такая унификация с лучшей опенсорсной реляционной СУБД — отличная идея.
К сожалению только в пределах одного процесса, т.е. shared не имеет особого смысла и сомнительный юзкейс
Почему сомнительный, разве он не подходит для async-операций в пределах одного процесса?
Для меня существенным минусом стало отсутствие case insensitive для non ASCII символов. Интересно, не собираются ли добавить функцию?
Она есть, но придется отдельно компилировать SQLite с поддержкой Unicode (SQLITE_ENABLE_ICU).
SQLITE_ENABLE_ICU
надо тащить большую библиотеку, а это не всегда хочется.Там какие-то дикие непонятки с sequence. Почему-то автор sqlite с недетской серьёзностью воспринимает автоинкременты, которые работают только в простейших случаях
Нет, общий вывод — что не стоит пренебрегать SQLite как рабочим инструментом — я поддерживаю, это действительно удобная система для некоторых вариантов использования.
Но, безусловно, не стоит пытаться воспринимать её как silver bullet, и пытаться встроить во все возможные и невозможные места.
Лично я, скорее, для части описанных в статье задач воспользуюсь Excel как более универсальным и простым инструментом, для других — более сложных — возьму более привычный мне SQL Server, благо у него тоже есть бесплатная версия, пусть чуть более сложная в первоначальной настройке, зато более привычная и удобная мне лично.
и с какой версии sqlite в import появился ключ --csv?
Можно и без него:
.mode csv
.import city.csv city
недавно заметил что некоторые проекты на .net core зачем-то подгружают sqlite. не знаю зачем
SQLite отлично подойдет вам в повседневной работе
Полностью согласен. Именно SQLite помог создать удостоверяющий центр CAFL63.
Поэтому я решил сделать нормальный набор библиотек, с разделением по предметной области и автоматической сборкой для всех ОС. Пока библиотек там немного, но скоро прибавится:
так значить, дело и было не в хорошести SQLite))
Работает отлично в Chrome, Firefox, старой Opera, мобильном Kiwi
База 4 Гига — всё летает.
SQLite — не игрушка