SQLite2
SQLIte установлен 1000000000000 (триллион) раз. Его разработкой руководят 3 (три) человека
https://www.sqlite.org/mostdeployed.html
2 поста-ответа
раскрыть ветку (27)
да обычно приложения свои данные там хранят.
какой-нибудь firefox - историю, закладки, пароли,
во всяком случае раньше так делал
ещё комментарии
раскрыть ветку (5)
так это физически и есть файл,
только данные там структурированные, с индексами и всем известным языком доступа,
ничего сочинять не надо.
раскрыть ветку (2)
так это физически и есть файл,
только данные там структурированные, с индексами
Как-то вот это мне и непонятно. Во "взрослых" БД индексы обычно хранятся в маленьких отдельных файлах, чтоб с ними было легче работать, отсортировать там по нужному критерию или найти какую-то запись опять же по критерию. Нашли, потом лезем в связанную по индексу большую таблицу достаем данные. Хорошо еще если индекс в кэш влазит, вообще работа в памяти ускоряется. А тут в sqlite как? Если это все в одном файле? Чтоб нужную запись найти нужно весь файл перелопатить? Ну и что что они стуктурированы, ведь чтоб нужную запись найти все-равно надо весь файл прочитать или как?
раскрыть ветку (1)
Чтоб нужную запись найти нужно весь файл перелопатить? Ну и что что они стуктурированы, ведь чтоб нужную запись найти все-равно надо весь файл прочитать или как?
ну не совсем, всё таки он тоже структурирован, движок по идее может сразу перейти к нужной странице, вроде как на 35% быстрее работает, чем с голыми файлами
но это уже частности
https://www.sqlite.org/fileformat.html
с другой стороны никто не обещает супер производительности от встраиваемой базы данных.
она не для этого придумана, а для относительно редких нагруженных и небольших баз
Ну в теории можно. Первый вариант это один огромный txt файл с записями, и при каждом запросе программа будет изучать весь файл, превращая записи в массивы и засирая всю память ради поиска закрытой минуту назад вкладки.
Второй вариант это использовать файловую систему, тогда каждая запись истории будет отдельным файлом с ссылкой и названием времени просмотра, в папках по дням, часам и так далее. В этом случае занимаемое место будет на пару тройку порядков выше необходимого а количество записей в файловой системе значительно снизит производительность операционной системы и ПК.
ещё комментарии
ещё комментарии
раскрыть ветку (2)
В обычных файлах как-то сложновато делать выборки данных по определенным критериям/запросам.
Нет, можно конечно, но придется писать какие-то свои костыли или подключать очередные специальные либы для этого.
В итоге - на кой фиг весь этот геморрой, если можно просто использовать SQLite?
ещё комментарии
Встроенная бд, для любителей ограничений SQL. На деле тормозная шляпа и в проектах используется только там где околонулевая нагрузка и низкая вероятность повреждений. А так же нет необходимости в быстрых бэкапах и специфики хранения на SSD.
Лучше гуглевского LevelDB, LSM дерева (и его форка от фейсбука RocksDB) пока ничего не придумали. Тут тебе все плюшки с трехуровневым кэшем и журнал, и мультитреадинг и сжатие и все полностью из коробки.
Только тссс.. пусть sqlщики думают что у них современные базы, а не надстройки над нормальными технологиями хранения. )
раскрыть ветку (10)
А ничего что это разные инструменты и забивать микроскопом молоток вообще не очень хорошая идея
ещё комментарии
раскрыть ветку (8)
sqLite - вам ни о чем не говорит?
это странно сравнивать микроскоп с молотком. еще и mysql тут припрели.
Ну для ряда операций b-деревья уделывают lsm все же- надо смотреть по юзкейсам, что лучше подходит в конкретном случае
ещё комментарии
для ряда операций? каких?
опять же речь не про "ряд операций" а про встроенное хранение, для чего и нужен sqlite.
Для встроенного хранения sqlite ни в чем никого не уделывает, хотя там конечно в итоге и b-tree, но я бы предпочел тот же sled (https://github.com/spacejam/sled тут на вкус и цвет фломастеры разные, но его атомарность это прорыв, я считаю) если уж очень хочется использовать устаревшие технологии.
Почему k-v? Да потому что в современных языках высокого уровня очень развита бинарная сериализация и всем уже давно лень раскладывать внутренние структуры в sql, проще сериализовать в json и положить в монго, если уж очень хочется чтобы было human readable. Если индексы критичны то их проще строить самому или пользовать известные библиотеки вторичного индекса или полнотекстового поиска.
раскрыть ветку (4)
ну очевидным образом b-дервья будут лучше на случайное чтение. Монга опять же хороша, но это не замена sql (и кстати там не json а bson внутри). Не буду холивар разводить - sql отличная штука, хотя sqllite для встроеного хранилища хорош только в одном случае, разработчик ни с чем кроме sql не умеет работать, а сделать надо вот прям сейчас
p.s за sled спасибо посмотрю
раскрыть ветку (3)
Если я планирую хранить сотню сущностей и мне только и надо что фильтровать по паре тройке полей и иногда джойнить с ещё одной сущностью, зачем мне изобретать велосипед а не использовать уже готовый инструмент который прямо создан для моих требований?
Для продакшна след не рекомендую, он в бете и легко ломается. Lsm тут вне конкуренции за счёт мемори маппед журнала. По всем пунктам согласен.
раскрыть ветку (1)
Так то да, но тачь предрид в сцепке с ноукей джиммером смотрится много перспективней, а уж если вложить триллекс мошен с визалом- то вообще вне конкуренции. А уж если вложить коллаб шестого уровня с версткой по дейбу- ток успей рефидь в прод. Так что да, к каждой задаче свои подходы
ещё комментарии
Если нужно тупое ключ значение хранилище то берем рок дб и если нужно связывать несколько сущностей или фильтровать по нескольким критериям ещё и в разных сценариях и данных относительно немного то sqllite почти вне конкуренции, если данных много то нужно смотреть на взрослые базы.
И да я рад за mysql и lsm деревья, но в чтении b+ дерево уделывает lsm
ещё комментарии
чтоб приложения раздувать до гигабайтов, зачем писать простейшую обработку чтения/записи в файл, лучше ебануть полноценную бд, с поддержкой sql, транзакций, кэширования и т.д. и т.п., а что, а вдруг понадобится
раскрыть ветку (3)
Что-что, но уж точно не sqlite раздувает объем приложений до гигабайтов. Да сложно назвать его полноценной субд, даже lite в названии намекает.
ещё комментарии
ещё комментарии