Приветствую. Пишу POS-систему. Для кассовых терминалов есть требование автономности - т.е. чтоб работало при пропадании инета. Думаю, что проще и удобнее всего будет держать на кассе локальную копию данных (цены, остатки, номенклатура), синхронизируемую с основным сервером учетной системы. На каждой точке продажи предполагаю локальный сервер, к которому в режиме клиента будут коннектиться остальные кассы. Всё это - на NodeJS/Electron. SQLite всем хорош, но очень не хотелось бы словить грабли, если потребуется многопоточная работа с базой (несколько инстансов сервера). Хочется чего-то легковесного, шустрого и встраиваемого. И желательно чтобы умело в индексный полнотекстовый поиск и поиск по сложным структурам (типа JSON/массивов). Что посоветуете? Спасибо.

Dimitry Sibiryakov, планирую так, что одна из машин на точке будет сервером. При этом сама POS-программа может работать в режиме клиента, сервера, или клиента и сервера. По сути задача сервера - отдавать кассе цены и остатки, и синхронизироваться с основным сервером. Всё было бы проще, если бы не требование автономности. Пока всё же смотрю на SQLite, но может есть варианты получше.

Dimitry Sibiryakov, сервером на точке является любая касса, и в случае отказа "серверной" кассы в нее мигом превращается любая другая.

Dimitry Sibiryakov, если делать вообще serverless, чтоб каждая касса автономная - то начинается адский гемор с остатками.

Остатки на кассе нужны, как минимум - для контроля. А ставить на точках полноценные СУБД не хотелось бы - оверхед. С пятью таблицами прекрасно справится и нода с какой-нибудь локальной СУБД. Вот и интересуюсь, может есть что поинтереснее SQLite

YuRock, чего такого нет в SQLite, без чего не получится обрабатывать пяток несложных таблиц? От кассы сверхспособностей не требуется, сверхспособности будут на бэкофисе.

YuRock, от практики использования ХП я уже давно ушел. Не нужны они, если так подумать.

Можно, конечно, на каждой точке постгрес фигануть, но ИМХО - это оверхед, как для 5 таблиц, которые всё равно генерируются сервером. И в случае падения этой "серверной" кассы перевести роль на другую гораздо сложнее. А тут элементарно, даже в автоматическом режиме: новая "серверная" касса просто запрашивает с основного сервера все нужные данные - и всё.

Нет, LAN не интересует. Если уж LAN упал - то полный ахтунг, пишите свет, тушите письма. А тюнинг - так, для бОльшего удобства.

Dimitry Sibiryakov, думаю ситуация, когда недоступен основной сервер, и намертво падает "серверная" касса - будут достаточно редки.

Накрайняк можно держать еще и резервную серверную кассу.

Думаю 5 минут, требующиеся для замены свитча, раз в 10 лет как-то переживут

В чем проблема передернуть пяток проводов? С этим и обезьяна справится.

Dimitry Sibiryakov, откуда столько желчи? Без инстанса oracle на каждой кассе жизни нет? Свитчи дохнут раз в пятилетку, и написать инструкцию, что делать в этом случае - вообще не проблема. Это не сеть гипермаркетов, а небольшие магазины, на максимум 3-4 кассы.

YuRock, спроектировано уже. Структура БД на кассе будет сильно упрощенная по сравнению со структурой на бэкофисе. Задача кассы - тупо выбивать чеки. Всё остальное - бэкофис. Вообще там есть уже софт, просто он не устраивает, есть куча специфических требований. Готового тоже особо нет, искали долго. Из предложений - либо 1с, либо не устраивает по другим причинам.

YuRock, Да, ты действительно из другой реальности. Оракл на магазинчик из 2-4 касс - это сильно. Очень сильно.

YuRock, сильно хотя бы тем, что саппорта этот оракл требует уж точно на порядок больше, чем тупой свитч. И инструкции на случай его отказа для охранника/продавца/местного мимокрокодила не напишешь. И сервак под него отдельный надо - единая точка отказа. Или резервировать сервак. Как-то слишком дохрена оверхеда там, где прекрасно справится SQLite.

YuRock, Баз в 2 гига там и близко не будет. Набитые чеки после отправки на основной сервер вообще планирую грохать (ну или хранить максимум неделю) - нафиг они там не нужны. Номенклатура - ну хорошо если 30000 позиций будет.

miksoft, так в том то и дело, что тут задача - тупая выбивалка чеков. Чем тупее - тем лучше, т.к. надежнее. Всё остальное будет жить на бэкофисе, в постгресе.

Хотя не совсем она тупая будет, как минимум перехватывать роль "сервера" в случае падения такового она должна будет уметь. Хотя там вообще ничего сложного в реализации нет. И до этого еще дойти надо.

miksoft, на точке LAN - это свитч и провода под плинтусами или в коробах. Или вайфай. Нечему там ломаться. Это не супер/гипермаркет, это небольшие магазины. А так - я и оракл знаю, работал с ним достаточно долго, но что-то не тянет его использовать. Постгрес гораздо приятнее, субьективно.

miksoft, блин, да не так всё. СУБД не должна это уметь. Изначально вопрос был про наличие локальных/встраиваемых микро-СУБД для NodeJS, кроме SQLite. Интересно было - может кто имел опыт их эксплуатации. Понятно, что за фейловер на точке будет отвечать приложение. И вообще, все кассы на точке будут работать со своим локальным сервером на этой же точке, и этот сервер - это то же кассовое приложение, просто на нем лежат данные, и другие кассы будут к нему бегать вместо использования своей локальной копии. Блин, ХЗ как еще понятнее объяснить, после праздников как-то мозги не особо варят.

miksoft, ы-ы-ы-ы... Блин, у вас тоже отходняк? Ну написал же. Его и использую. На бэкофисе. Но на точке он нафиг не нужен. Там нужно дубовое и быстроразворачиваемое приложение.

Товароведы, менеджеры и прочая 3.14здабратия будет обитать в нормальном ВЕБ-приложении. Задача кассы - тупо набить чек, и раз в N минут отправить набитые чеки на удаленный сервер, если есть инет. Если инета нет - отправить, когда появится. И получить с того же сервера обновления номенклатуры, остатков (это больше для удобства кассира) и карт лояльности. Всё. Других задач у кассы нет.

miksoft, зачем бегать... Есть точка. На ней - условно три кассы. Интернет - нестабильный. Зачем синхронизировать все 3 кассы, если можно синхронизировать одну-две (одна - резервная), а остальные за данными будут ходить к ней? И контроль остатка на точке в этом случае сильно упрощается, хоть и делается чисто для удобства и самоконтроля (требование есть такое у заказчика).

miksoft, а какие такие флешбеки накатили?

miksoft, быстроразворачиваемое - это один AppImage, который при запуске сам создаёт себе БД, запускает первичную синхронизацию, если этой самой БД еще нет, и запускается в выбранном режиме (клиент, сервер, клиент-сервер). Электрону вообще пофигу, куда за данными бегать, оно само по себе такое себе "клиент-локальный сервер".

YuRock, посоветоваться зашел, пообщаться. Жалко чтоли? Или просто покозлить кого-то хочется?

Это всё будет выдаваться кассе в максимально переваренном формате. Задача кассы - всё это максимально быстро обработать. Тот софт что есть, видимо по вашим рецепрам сделанный, тормозит просто таки адово.

YuRock,

*facepalm.jpg*

Я вроде писал, что как раз наличие локального сервера на точке и необходимо для грамотной работы с остатками, чтоб оно на точку считалось, а не на кассу (хотя там оно считается на "склады", но то не суть важно, это логическое разделение, и требование заказчика).

Тот софт с инетом работает как раз в том же режиме синхронизации. А то, что писали криворукие - согласен. https://chm-s.com/ - вот эти, советую держаться от них подальше.