The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года , opennews (?), 04-Янв-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


36. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  –1 +/
Сообщение от Аноним (5), 04-Янв-24, 15:10 
Ну так SQLite-базу обычно одно локальное приложение и пишет одновременно. Поэтому многопользовательность и прочие сложности обеспечения консистентности тут не нужны. В SQLite больше всего бесит отсутствие схемы, что приводит к оверхэду на хранение. Кому надо покомпактнее без сложных SQL-запросов - тому наверное лучше метакит или вообще LMDB.
Ответить | Правка | Наверх | Cообщить модератору

37. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  –1 +/
Сообщение от Аноним (37), 04-Янв-24, 15:17 
>>Ну так SQLite-базу обычно одно локальное приложение и пишет одновременно.

Это не так...

Ответить | Правка | Наверх | Cообщить модератору

48. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  –1 +/
Сообщение от Аноним (26), 04-Янв-24, 16:48 
Ну попробуйте из двух приложений одновременно писать в одну базу данных SQLite.
Ответить | Правка | Наверх | Cообщить модератору

51. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  –1 +/
Сообщение от Аноним (5), 04-Янв-24, 16:52 
Ну вообще можно и делается, но если такой use case не является целевым, то лучше заблокировать базу эксклюзивно, и производительность операций с ней вырастет.
Ответить | Правка | Наверх | Cообщить модератору

60. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  –3 +/
Сообщение от Аноним (37), 04-Янв-24, 18:51 
да. имеено поэтому sqlite значительно превосходит в скорости записи и чтения все серверные субд, но не во всех случаях может бытьиспользован
Ответить | Правка | Наверх | Cообщить модератору

63. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/
Сообщение от Аноним (26), 04-Янв-24, 19:01 
> имеено поэтому sqlite значительно превосходит в скорости записи и чтения все серверные субд

Пользователи Redis с вами не согласятся.

Ответить | Правка | Наверх | Cообщить модератору

132. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/
Сообщение от Аноним (131), 05-Янв-24, 12:30 
Бенчмарки в студию. Но только чтобы эти данные вот прям сохранялись, а не "мы тут что-то в память прихранили, но если свет моргнёт, то продолбаем вообще всё, ещё и старые данные развалим"
Ответить | Правка | Наверх | Cообщить модератору

149. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/
Сообщение от Аноним (37), 05-Янв-24, 16:01 
более того я уверен что sqlite в режиме inmemory уделает redis очень просто )))
Ответить | Правка | Наверх | Cообщить модератору

111. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/
Сообщение от Антонимусс (?), 05-Янв-24, 07:37 
`PRAGMA journal_mode = wal2;` и пишите сколько нужно.
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

61. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +2 +/
Сообщение от Аноним (180), 04-Янв-24, 18:55 
>  В SQLite больше всего бесит отсутствие схемы, что приводит к оверхэду на хранение.

Ещё один размороженный. Добро пожаловать в 2024-ый, уже 20 лет прошло с твоей заморозки, мир сильно изменился

https://www.sqlite.org/version3.html
https://www.sqlite.org/fileformat.html

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

73. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/
Сообщение от Аноним (5), 04-Янв-24, 20:03 
>Record Format
>A record contains a header and a body, in that order. The header begins with a single varint which determines the total number of bytes in the header.

Для тех кто в танке: каждое значение имеет заголовок с типом, при этом даже если в DDL указан один тип, в ячейку можно записать другой, и база это переварит, а у тебя проблема вылезет при чтении такой записи. Это какой-то полу-BSON, что приводит к оверхеду на каждый элемент. А если у тебя миллиарды этих элементов?

Да ещё значения хранятся в Big Endian, что идиотизм, так как абсолютно все актуальные машины сейчас - это little endian, и вообще придумать использовать big endian - это извращенцем или вредителем быть надо, ибо элементарнейшие действия, в LE получаемые абсолютно бесплатно, в BE требуют кода и знания длины числа. Проблема решается тривиально: выпустить новый формат на основе little endian, выпустить in-place конвертор в оный, просто мапящий всю базу, находящий все куски с числовыми float-полями, какое-то время подержать поддержку в коде самой базы, потом какое-то время добавить автоконвертацию, а потом старый формат вообще дропнуть. Кому надо - сконвертят.

Ответить | Правка | Наверх | Cообщить модератору

75. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  –1 +/
Сообщение от Аноним (75), 04-Янв-24, 20:30 
Ну так выпусти!
Тут тебе никто ничего не должен...
Я дажe название подскажу: "SQLiteLE"
Ответить | Правка | Наверх | Cообщить модератору

133. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/
Сообщение от Аноним (131), 05-Янв-24, 12:31 
Звучит как боль чувачка, который не смог в ORM и нормальные миграции
Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

153. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +1 +/
Сообщение от Аноним (153), 05-Янв-24, 17:02 
ORM - это говно, которое имеет смысл использовать только поверх key-value хранилища. Потому что смысл ORM - это просто прозрачное для прогркммиста получение данных по ключу и сохранение данных по ключу, а все операции делаются на стороне приложения. Для этого движок SQLite с индексами, оптимизацией сложных запросов и оверхедом на всё это просто избыточен: сам ORM строить подобные запросы не умеет. SQL используют там, где надо не просто хранить бизнес-данные, но ещё эффективно их выбирать, пересылая только те, что нужны, и модифифировать, избегая ненужных запросов. Поэтому у меня используется ванильный SQLite + ООП-обвязка + мои кастомные запросы, оптимизированные вместе со схемой. Но не ORM.
Ответить | Правка | Наверх | Cообщить модератору

174. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  –1 +/
Сообщение от Аноним (43), 05-Янв-24, 19:55 
Не стоит демонизировать орм, это отличная штука на практике. Большинство практических задач решаются только на уровне орм, да и построитель запросов в любом случае необходим. Кроме того, он позволяет сосредоточиться на логике приложения. Просто надо уметь с ним работать. Ну и понимать ограничения (а у каждой реализации будет своя специфика).
Ответить | Правка | Наверх | Cообщить модератору

176. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/
Сообщение от Аноним (43), 05-Янв-24, 19:59 
>SQLite с индексами, оптимизацией сложных запросов и оверхедом на всё это просто избыточен: сам ORM строить подобные запросы не умеет

я не знаю, что у тебя за орм, но нормальный орм всё это умеет, и, кроме того, позволяет всё настроить дополнительно, для уровня базы, при этом, у тебя остаётся уровень орм для интересных вещей, поддержка которых не реализуема эффективно в сикуль

Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

179. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +3 +/
Сообщение от Аноним (180), 05-Янв-24, 21:07 
ORM есть смысл использовать только когда совсем не умеешь работать с базами данных
Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

178. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/
Сообщение от Аноним (180), 05-Янв-24, 21:02 
Ок, проблема понятна. Да, неприятная особенность SQLite. Только это не проблема эффективности хранения и отсутствия схемы, а проблема отсутствия ограничений по типу. Хранение тут более-менее эффетивное, но не самое оптимальное. LE или BE для СУБД вообще никакого значения не имеет, считай это особенностью кодирования. СУБД может хранить числа как угодно, хоть всё в VARINT-ах или поколоночном delta кодировании на битах. LE или BE имеет значение толлко когда есть возможность работать с данными прямо из хранилища, SQL СУБД такой фичей не обладают.
Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру