litedb активно развивается, много звезд. удобен в первом приближении.
опасение — много открытых багов. возможность наступить на грабли по незнанию.
sqlite — классический, проще работать со структурой, но сложнее внедрить в проект особенно в конфигурации any cpu.
требуется написание ado-прослойки для манипуляции с данными.
Кто-нибудь использует litedb в проде?
Что выбрать для хранения промежуточных данных для настольного приложения?
Слегка разочарован. лайтдб работает только с get\set свойствами.
вообщем любой автомат имеет оборотную сторону.
Здравствуйте, vaa, Вы писали:
vaa>litedb активно развивается, много звезд. удобен в первом приближении. vaa>опасение — много открытых багов. возможность наступить на грабли по незнанию.
vaa>sqlite — классический, проще работать со структурой, но сложнее внедрить в проект особенно в конфигурации any cpu.
неа. как раз вопросом "any cpu" занимается microsoft. смотри, она собирает оптимизиранную и независимую от os sqlite под каждый runtime.
vaa>требуется написание ado-прослойки для манипуляции с данными.
необязательно. юзай напрямую с entity framework. не юзай ado если не знаеш зачем он.
VC>неа. как раз вопросом "any cpu" занимается microsoft. смотри, она собирает оптимизиранную и независимую от os sqlite под каждый runtime.
разве? native dll отдельно всегда идут в папки x86 x64. может я не ту версию использовал.
Там другая проблема. когда System.Data.SQLite.Core в отдельном от главного проекте, то при сборке SQLite.Interop.dll не копируется автоматом в выходной каталог приложения.
у меня этим отдельная таска занимается.
VC>необязательно. юзай напрямую с entity framework. не юзай ado если не знаеш зачем он.
По опыту работы с entity framework, ado намного проще, тут вопрос в том что litedb как раз в разы проще.
смущает только что с такой моделью не работал, там миграции всякие и прочее.
плюс еще зависимости. чтобы более менее комфортно работать в склайт нужен еще даппер и даппер-контриб.
Бенчил. без транзакции намного быстрее лайтдб, с транзакциями 17/14 выигрывает склайт. т.е. тут более менее все ровно.
>Здравствуйте, vaa, Вы писали:
VC>>неа. как раз вопросом "any cpu" занимается microsoft. смотри, она собирает оптимизиранную и независимую от os sqlite под каждый runtime. vaa>разве? native dll отдельно всегда идут в папки x86 x64. может я не ту версию использовал.
есть еще мас ос и линукс
vaa>Там другая проблема. когда System.Data.SQLite.Core в отдельном от главного проекте, то при сборке SQLite.Interop.dll не копируется автоматом в выходной каталог приложения. vaa>у меня этим отдельная таска занимается.
не. эта проблема только у тебя в голове. чего не юзаеш Microsoft.Data.Sqlite, она any cpu
System.Data.SQLite.Core (от SQLite) ей 8 месяцев всего. зачем она? есть же Microsoft.Data.Sqlite
VC>>необязательно. юзай напрямую с entity framework. не юзай ado если не знаеш зачем он.
vaa>По опыту работы с entity framework, ado намного проще, тут вопрос в том что litedb как раз в разы проще.
ты написал "требуется написание ado-прослойки для манипуляции с данными." а теперь ado намного проще?
vaa>смущает только что с такой моделью не работал, там миграции всякие и прочее. vaa>плюс еще зависимости. чтобы более менее комфортно работать в склайт нужен еще даппер и даппер-контриб.
у тебя еще и с dapper проблема?
vaa>Бенчил. без транзакции намного быстрее лайтдб, с транзакциями 17/14 выигрывает склайт. т.е. тут более менее все ровно.
не морочь людям голову. попробуй разбить на несколько вопросов — крофссплатформенность, сфера принименения и производительность.
VC>>неа. как раз вопросом "any cpu" занимается microsoft. смотри, она собирает оптимизиранную и независимую от os sqlite под каждый runtime. vaa>разве? native dll отдельно всегда идут в папки x86 x64. может я не ту версию использовал. vaa>Там другая проблема. когда System.Data.SQLite.Core в отдельном от главного проекте, то при сборке SQLite.Interop.dll не копируется автоматом в выходной каталог приложения. vaa>у меня этим отдельная таска занимается.
Зачем таска,когда copy always достаточно? Или речь о nuget? Там возможны приседания.
Здравствуйте, Sharov, Вы писали:
VC>>не. эта проблема только у тебя в голове. чего не юзаеш Microsoft.Data.Sqlite, она any cpu
S>К anycpu нужны соотв. interop dll'ки.
еще их нужно положить в нужное время в нужное место.
Совершенно верно, как я и писал, ссылка на пакет в зависимом проекте, при сборке каталоги с нативками не копируются в выходной каталог главного проекта.
VC>не. эта проблема только у тебя в голове. чего не юзаеш Microsoft.Data.Sqlite, она any cpu
попробовал, да, работает, но отдельно требует "батарейки" (без шуток — нужно гуглить в каком пакете они есть, на мсдн ни намека на это).
речь конечно о net472.
VC>System.Data.SQLite.Core (от SQLite) ей 8 месяцев всего. зачем она? есть же Microsoft.Data.Sqlite
Может на нугете она недавно, а сама библиотека гораздо старше.
VC>ты написал "требуется написание ado-прослойки для манипуляции с данными." а теперь ado намного проще?
просто хотел сказать что без знания адо сложно пользоваться ЭФ.
VC>у тебя еще и с dapper проблема?
Р. Мартин советует избегать ненужных зависимостей.
VC>не морочь людям голову. попробуй разбить на несколько вопросов — крофссплатформенность, сфера принименения и производительность.
постараюсь. речь конечно об удобстве разработки приложения.
Это несравнимые вещи. sqlite это почти полноценная РСУБД, а litedb это просто движок персистентных данных с минимальным функционалом.
vaa>litedb активно развивается, много звезд. удобен в первом приближении.
Так развивается, что до сих пор async методов не завезли, это в 2021 то году. На практике — легко и непринужденно портит файл БД, т.е. пригоден только для хранения не особо ценных данных.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Так развивается, что до сих пор async методов не завезли, это в 2021 то году. Q>Так в SQLite и Microsoft.Data.Sqlite тоже не завезли: Q>
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Qbit86, Вы писали:
Q>>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Так развивается, что до сих пор async методов не завезли, это в 2021 то году. Q>>Так в SQLite и Microsoft.Data.Sqlite тоже не завезли: Q>>
S>https://www.sqlite.org/asyncvfs.html
По ссылке не та асинхронность которая обычно имеется ввиду.
Там говорится, о том что операции записи помещаются в отдельную очередь и затем фоновым потоком выполняются,
основной вызов (который вызывает запись) при этом не блокируется и завершается не дожидаясь физического окончания записи — это и имеется в виду под асинхронностью.
Но возникают вопросы.
А зачем это вообще надо? Если ОС и так поддерживает асинхронную запись. То есть запись сначала происходит в кэш ОС и ОС затем сама в фоне флушит буфера на диск.
С учетом этого и потребность в .net асинхронности сомнительна при операциях записи, тк вызов по сути отрабатывает синхронно и никакого ожидания (без выполнения работы) в нём не происходит.
Асинхронность одна и та же, просто механизмы разные -- отдельный поток или non-blocking io (через callback).
MH>Но возникают вопросы. MH>А зачем это вообще надо? Если ОС и так поддерживает асинхронную запись. То есть запись сначала происходит в кэш ОС и ОС затем сама в фоне флушит буфера на диск.
Так речь идет не просто о записи, а о бд, т.е. у нас здесь consistency и durability. Возможно, что с ними будут проблемы при использовании
кэшей ОС. Напрямую надежнее.
MH>С учетом этого и потребность в .net асинхронности сомнительна при операциях записи, тк вызов по сути отрабатывает синхронно и никакого ожидания (без выполнения работы) в нём не происходит.
Не понял этот фрагмент -- почему синхронно и почему никакого ожидания не происходит (кого, в чем ?) ?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, MadHuman, Вы писали:
S>>>https://www.sqlite.org/asyncvfs.html MH>>По ссылке не та асинхронность которая обычно имеется ввиду.
S>Асинхронность одна и та же, просто механизмы разные -- отдельный поток или non-blocking io (через callback).
я хотел сказать что разница в следующем — в 1-м случае работа запускается асинхронно и будет сделана позже и вызывающая
сторона не ждет и никак не узнает что работа зафейлилась (что довольно редко в рассматриваемом кейсе).
а во 2-м (то что в .net обычно подразумевают под асинхронностью, через калбэк) — вызывающая сторона асинхронно ожидает завершения работы
и если что не так, то получит ошибку и может обработать.
MH>>С учетом этого и потребность в .net асинхронности сомнительна при операциях записи, тк вызов по сути отрабатывает синхронно и никакого ожидания (без выполнения работы) в нём не происходит. S>Не понял этот фрагмент -- почему синхронно и почему никакого ожидания не происходит (кого, в чем ?) ?
когда в .net мы вызываем запись в файл, то (в большинстве случаев) запись сначала происходит во внутренний буфер ОС и управление сразу возвращается вызывающей стороне.
ОС уже сама потом асинхронно флушит буфера на диск. В этом случае смысла запускать по сути синхронный метод в асинхронном варианте нет (кроме конечно хитрых кейсов, когда расклад будет не такой — данные не вошли в буфер, он переполнен и тп).
Здравствуйте, MadHuman, Вы писали:
S>>Асинхронность одна и та же, просто механизмы разные -- отдельный поток или non-blocking io (через callback). MH>я хотел сказать что разница в следующем — в 1-м случае работа запускается асинхронно и будет сделана позже и вызывающая MH>сторона не ждет и никак не узнает что работа зафейлилась (что довольно редко в рассматриваемом кейсе). MH>а во 2-м (то что в .net обычно подразумевают под асинхронностью, через калбэк) — вызывающая сторона асинхронно ожидает завершения работы MH>и если что не так, то получит ошибку и может обработать.
Тут отличие, что в случае отдельного потока результат записи придется poll'ить из какой-то расшаренной структуры.
Узнать то узнает, но насколько данный процесс эффективен. Опять же, мы говорим о бд и транзакциях, насколько там
уместна вся эта асинхронщина (любым способом), я
MH>>>С учетом этого и потребность в .net асинхронности сомнительна при операциях записи, тк вызов по сути отрабатывает синхронно и никакого ожидания (без выполнения работы) в нём не происходит. S>>Не понял этот фрагмент -- почему синхронно и почему никакого ожидания не происходит (кого, в чем ?) ? MH>когда в .net мы вызываем запись в файл, то (в большинстве случаев) запись сначала происходит во внутренний буфер ОС и управление сразу возвращается вызывающей стороне. MH>ОС уже сама потом асинхронно флушит буфера на диск. В этом случае смысла запускать по сути синхронный метод в асинхронном варианте нет (кроме конечно хитрых кейсов, когда расклад будет не такой — данные не вошли в буфер, он переполнен и тп).
Про это я в курсе, просто насколько всяческие кэши актуальны для бд и consisntency и durability. Т.е. бд нужны 100% гарантии, что
мы записали на диск, а не только в кэш ОС. Опять же, не в контексте бд, маленькие порции данных можно писать и синхронно,
а вот большие уже лучше асинхронно.
MH>>>>С учетом этого и потребность в .net асинхронности сомнительна при операциях записи, тк вызов по сути отрабатывает синхронно и никакого ожидания (без выполнения работы) в нём не происходит. S>>>Не понял этот фрагмент -- почему синхронно и почему никакого ожидания не происходит (кого, в чем ?) ? MH>>когда в .net мы вызываем запись в файл, то (в большинстве случаев) запись сначала происходит во внутренний буфер ОС и управление сразу возвращается вызывающей стороне. MH>>ОС уже сама потом асинхронно флушит буфера на диск. В этом случае смысла запускать по сути синхронный метод в асинхронном варианте нет (кроме конечно хитрых кейсов, когда расклад будет не такой — данные не вошли в буфер, он переполнен и тп).
S>Про это я в курсе, просто насколько всяческие кэши актуальны для бд и consisntency и durability. Т.е. бд нужны 100% гарантии, что S>мы записали на диск, а не только в кэш ОС.
не всегда. в той же sqlite это регулируется опцией, и как-токо включаем синхронный флуш на диск, производительность ожидаемо существенно падает.
там на самом деле ещё ряд кешей кроме ОС (у самого контроллера диска) и хз достижима ли полная синхронность.
и ослабление гарантии вполне ок, т.к. если питание не прервётся, то запись на диск всё равно практически гарантированно произойдет.
хотя даже если прервётся, есть свои меры — УПСы, конденсаторы и т.п.
Здравствуйте, Sharov, Вы писали:
S>Тут отличие, что в случае отдельного потока результат записи придется poll'ить из какой-то расшаренной структуры. S>Узнать то узнает, но насколько данный процесс эффективен. Опять же, мы говорим о бд и транзакциях, насколько там S>уместна вся эта асинхронщина (любым способом), я
Асинхронщина в БД вполне уместна. Если посмотреть в учебник, то более-менее передовым методом достижения Durability является Undo/Redo Log. (См. напр. https://www.cs.sjsu.edu/faculty/pollett/157b.12.05s/Lec20042005.pdf).
То есть изменения в сами данные можно сбрасывать на диск в любом порядке. Например, можно просто отмапить файл в память и дать ОС самой решить, что и когда записывать на диск.
А вот порядок записи в лог — важен; более того, если вас интересует durability, т.е. вы не хотите получить ситуацию, когда транзакция, подтверждение которой уже уехало клиенту, внезапно исчезает после рестарта, то нужно не просто запихивать записи в определённом порядке, но и (синхронно) дожидаться подтверждения окончания записи перед ответом клиенту.
S>Про это я в курсе, просто насколько всяческие кэши актуальны для бд и consisntency и durability. Т.е. бд нужны 100% гарантии, что S>мы записали на диск, а не только в кэш ОС. Опять же, не в контексте бд, маленькие порции данных можно писать и синхронно, S>а вот большие уже лучше асинхронно.
Тут сложный вопрос. Во-первых, диску удобнее работать большими блоками. Большинство современных дисков вообще не умеют записывать порции меньше, чем страница, т.е. от 4 до 16kb.
Многие умеют в один "приём" прожёвывать от 64kb и выше.
Поэтому, скажем, синхронно записать один мегабайт — это как бы норм, накладных расходов минимум. А вот если мы будем писать по 1kb, да ещё и с write-through, то это рискует затянуться надолго.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, MadHuman, Вы писали:
MH>не всегда. в той же sqlite это регулируется опцией, и как-токо включаем синхронный флуш на диск, производительность ожидаемо существенно падает. MH>там на самом деле ещё ряд кешей кроме ОС (у самого контроллера диска) и хз достижима ли полная синхронность. MH>и ослабление гарантии вполне ок, т.к. если питание не прервётся, то запись на диск всё равно практически гарантированно произойдет. MH>хотя даже если прервётся, есть свои меры — УПСы, конденсаторы и т.п.
Есть пропасть между "практически гарантированно" и "я не получу кашу в файле".
Самый замечательный УПС имеет свои ограничения, и если не проектировать протокол записи на диск так, чтобы он был устойчив к сбоям, то рано или поздно УПС таки выдохнется, и вот эта вот "последняя неудачная запись" запросто убъёт вам неограниченный объём данных.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>То есть изменения в сами данные можно сбрасывать на диск в любом порядке. Например, можно просто отмапить файл в память и дать ОС самой решить, что и когда записывать на диск.
Если речь об одной и той же строке данных в бд, то порядок важен.
