Комментарии 16
Как надо не любить читателей чтобы советовать им Isar ? Достаточно посмотреть что она уже больше года не обновляется, а обещанная 4 версия и того дольше "в разработке" находится. Вещь совершенно не юзабельная. Да хотяб просто вспомнить что Isar - это поменявший название и много вызвавший негатива в прошлом Hive! В нем остались все те же проблемы и добавилось еще куча новых. Чтобы потом не пришлось переезжать - используйте Sqlite или ОРМ для него Drift. Вообще не используйте NoSQL решения в проектах чуть сложнее калькулятора - потом будет больно переписывать!
Для ряда проектов SQL просто не позволит физически реализовать функционал-в силу чудовищной стоимости либо невозможности на текущем железе поднять инфру. Какой-нибудь средненький HFT фонд, катающий скромные 100М уе объема в сутки, желающий держать на своих серверах хотя бы сотню торгуемых инструментов-легко запишет весь требуемый датафид, используя EventSource/CQRS/NoSQL, с требуемой скоростью доступа к материализованному представлению по этим данным, правильно заточенному-будь то OrderBook либо подготовленные данные под ML, SQL на любой платформе и на любом железе для такого скромного набора датафидов скажет-"наши полномочия всё" :) А ведь есть те конторы, что хранят тысячи датафидов десятков бирж :) Кто-то правда еще дальше пошел и использует kdb+, но у него свои нюансы, начиная от стоимости, заканчивая пиковым перформансом, при прямых руках собственные реактивные велосипеды выходят шустрее.
Разговор именно про встраиваемую БД. На серверах можно использовать что угодно. Там у NoSQL решений нет таких проблем с безопасностью, производительностью и масштабируемостью как на мобилках.
1000 датафидов спокойно отображается в 1000 SQLite файлов. Так что SQL вам дозволит проводить обработку. В этом случае все-равно будет многопоточность приложение и большинство данных будут просто держаться в памяти. База нужна в редких случаях чтобы исторические данные подтянуть. А там где реальный HFT ( когда считают наносекунды потерянные на передачу данных по оптическому каналу) все равно будут использовать что-то своё и узко специализированное
Я вот с Isar переехал на sqlite с Drift и столкнулся с неожиданной багой. На проде и только на проде Drift периодически выбрасывает DriftRemoteException (Code 5) хотя подключение к БД открываю только один за время жизни приложения. Специально локально писал нагрузочные тесты с асинхронными запросами что бы воспроизвести проблему локально, но так и не получилось воспроизвести проблему. Я в итоге шаманствами с подключениям жизненного цикла пофиксил проблему, но осознанного и уверенного решения проблемы так и не получил. Поэтому и с Drift надо идти на прод осторожно.
Для хайлоада с 1М+ запросов на модификацию NoSQL гораздо предпочтительнее.
Для 10М+ только NoSQL и остается.
Хотя очевидно, что подобные требования нужны 0.0001% проектам :)
Похоже чат-ГПТ голлюцинирует….
Если вы делаете маленькое приложение на узкую аудиторию или если вы делаете MVP для проверки гипотезы, то можно смело выбирать NoSQL-решение. Такие базы быстрые, с ними проще работать, они легко масштабируются. А если проект растет как на дрожжах — NoSQL можно быстро переписать на SQL
Удачи вам NoSQL в SQL переделывать….
Похоже автор вообще в руках баз данных не держал. Сравнивать абстрактный nosql с абстрактным sql на техническом ресурсе это уже за гранью добра и зла
если свести всю статью к одной фразе:
Не знаете как делать- берите SQLite.
Будет шанс смигрироватт на PostgreSQL без большой головной боли. Или раскидаете данные по разным SQLite базам - скорее всего вы не Google и не FB и SQLite покроет потребности всех ваших 10-100 клиентов
Чет я довольно сильно сомневаюсь что постгрю можно в принципе на мобилке развернуть. И что это вообще кому нибудь нужно.
С другой стороны в этом плане проблема в статье. Почему то сравниваются именно для мобилок базы встраиваемые, а в конце вывод делается почему то для бека. Так что тоже склоняюсь к выводу что статью писали либо совсем невнимательно, либо нейронка.
Выбор между SQL и noSQL это, как по мне, выбор между дрелью и молотком. Как вообще можно между ними выбирать? Да еще и с прицелом "сначала возьму одно, а потом, мб перепишу на другое". Это так не работает. Не хотел бы я в штате иметь архитектора, который выбирает между noSQL и SQL. Очевидно, что этот архитектор просто профнепригоден и не понимает, что делает.
Если нужно работать с цельными сущностями и тебе нужно просто "тупое хранилище", используй для этой цели noSQL, ведь просто SQL будет оверкиллом. Если нужно работать с декомпозированными данными - используй SQL, ведь...ды просто а что тебе еще использовать? :)
Это, блин, штуки, для разных задач. У них из общего - только 3 символа в названии подхода к работе. Но так-то и дрель с молотком это "строительные/монтажные инструменты" , да?
Хайп вокруг nosql давно прошел когда стало очевидно что "серебряной пули" из них не получилось и nosql базы заняли отвдеенную им нишу быстрой обработки больших объемов key-value данных
Если вы делаете маленькое приложение на узкую аудиторию или если вы делаете MVP для проверки гипотезы, то можно смело выбирать NoSQL-решение. Такие базы быстрые, с ними проще работать, они легко масштабируются.
И часто у вас в маленьких приложениях на узкую аудиторию не хватает производительности СУРБД или возникает потребность в горизонтальном масштабировании?
Если вы делаете энтерпрайз-решение
То у вас, вероятно, будет множество разнотипных баз данных.
Базы данных NoSQL быстрые и легкие.
Давно например MongoDB лёгкой-то стала?
SQL vs NoSQL: как выбрать архитектуру БД для мобильного приложения, чтобы потом не пришлось ничего переписывать
И сразу вспомнилось:
Четырнадцатый том сочинений Боконона озаглавлен так: «Может ли разумный человек, учитывая опыт прошедших веков, питать хоть малейшую надежду на светлое будущее человечества?» Прочесть Четырнадцатый том недолго. Он состоит всего из одного слова и точки: «Нет.»
«Колыбель для кошки»
Исходя из статьи, такое ощущение, что бд хранится у каждого пользователя приложения своя, сервер с API не нужен или вообще без БД. Почему у меня такое ощущение? Потому что ни слова про запросы API и сервер и потому, что автор писал, что если пользователь заероет приложение, то данные в noSQL не сохранятся или сохранятся битые.
То ли я не понимаю подхода, который использует автор, то ли автор не понимает, как пользоваться базами данных.
1) Странно, сначала автор говорит про мобильные приложения, а потом приводит таблицу в каком языке какой инструмент используется, но язык не привязан к мобильному приложению. И на телефонах/планшетах исходно используется SQLite, а не SQL - что в Android, что в iOS.
2) не понятен ни разу вывод о скорости, вроде с одной стороны говорится, что SQL-решения быстрее, но в тоже время почему-то рекомендуется NoSQL.
Мои личные замеры в этом плане на Android на простой табличке с плоской структурой 50-100 тыс записей, говорили, что Realm в 2 раза медленнее вычитывает данные, чем Room (а он далеко не оптимизированный в этом плане, и тоже вычитывает целиком данные), а если возьмем чистый SQLite с и оптимизируем запросы - то скорость повысится еще сильнее.
Был опыт переезда с Realm (NoSQL) на SQLDelight (SQLite под капотом) без оптимизиции глобальной запросов - скажу я вам - то еще удовольствие, и это явно не тот случай когда попробуем на NoSQL, а потом если вырастим - то перейдем на SQLite. Никто не перейдет если не упретесь в проблемы, а переезд будет стоить очень дорого.
Так вот, после переезда приложение смогло переваривать раза в 2 больше данных не подвисая, при этом кушать куда меньше памяти.
Вы могли просто написать "На мобилках ничего, кроме SQLite не имеет смысла, так как для SQLite, для какой бы платформы ты не писал, есть библиотека от создателей платформы, которая справится со всем, что нужно для базы данных, встроенной в приложение". Вместо этого, вы описали помимо этого кучу несуществующих, сырых, устаревших и просто упоротых вариантов. Статья фигня.
SQL vs NoSQL: как выбрать архитектуру БД для мобильного приложения, чтобы потом не пришлось ничего переписывать