OberonCore

по тестам простой cgi скрипт (Hello World) на oberon медленнее php (в режиме mod_php) всего лишь в несколько раз.
при этом определенно сам вычислительный процесс на oberon должен быть быстрее.
так что идея имее тправо на жизнь.

портит малину то что XDS не компилирует в x64 (а 32bit приложения не запускаются на сервере).
а если использовать транслятор типа ofront+ или XDS-C - появляется зависимость от gcc и реализация данной схемы становится намного сложнее т.к. установить свои пакеты с компилятором и другими инструментами не возможно.

парадокс - XDS хорошая система которая разворачивается всего лишь распаковкой архива - но имеет мало практического применения из за отсутствия x64 версии.

- во первых сущесвующие NoSQL - это универсальные системы написанные на низкоуровневых языках С/С++. что требует значительных ресурсов на изучение работы систем.
- во вторых нужно ежемесячно платить деньги за сервисы типа redis или tarantool или админить самому на vds.

применение простого и более высокоуровнего oberon для реализации частной модели данных было бы простым и доступным для широких масс вариантом.
т.к. по сути это просто алгоритм обработки с вшитым набором данных.

Это справедливо в гораздо более общем контексте. Хорошо, что можно выразить мысль цитатой, а не от своего имени. Цитата всегда звучит убедительней

Хабра на вас нет.
Riak написан по большей части на Erlang, CouchDB - на Erlang. Плюс к тому, это нисколько не универсальные системы.
За что нужно платить? За Redis, Tarantool? Мы с вами, похоже, на разных планетах живем.
Админить самому VDS? В чем проблема?

Толсто...

Это всё не имеет отношения к сути. А суть такова - описаная Вами схема будет работать, если не нужен функционал SQL, поэтому и сравнивать нужно было тоже не c более общим и медленным MySQL, а с более быстрыми NoSQL вариантами. Такое сравнение имело бы смысл, а если заведомо исключать более подходящие способы из сравнения, то можно прийти к любым выводам, но пользы от них будет мало.

это интересная идея - рассыпается только об объективную реальность того что не возможно установить эрланг на мой хостинг. кроме того функциональная парадигма - это совершенно иной подход нежели простой императивный.

а вот инструменты компилироания oberon кода поставить впринципе можно. хотя на данный момент не очень то и просто это.
а хотелось бы что то типа Roslyn - чтобы просто можно было компилировать через api или хотябы просто компилятор в виде 1 исполнимого файла который просто копируеш куда хочешь - тогда генерим код модели, компилируем, запускаем или демона или CGI который выдает результаты обработки. и не нужны никакие эрланги и тарантулы и лишние рты.


платить естественно за тех. поддержку серверов с Redis, Tarantool придется - это вроде элементарно.


вы будете за бесплатно админить мои VDS сервера? дежурить по ночам, хорошо? если нет - в чем же проблема?

суть в том чтобы ускорить вычисления и снизить нагрузку - как NoSQL решают эту задачу по сравнению с исполнимым кодом?
NoSQL это тупо key value хранилище с набором универсальных функций, причем работающее через сетевое соединение.
веть чтобы сделать обработку данных вы пишете код который сначала берет данные из nosql хранилища они передаются по сети - потом конвертирует в пригодный вид потом обрабатывает потом выдает результат.

Хорошо, зайдем с другой стороны. Тесты в студию.
Это раз.

Какую задачу решаем? Это два.

Что-то из всех высказываний не видно реальную задачу, только болтовня.

С какими NoSql системами есть опыт работы?
У меня вот очень хорошие впечатления от CouchDB, MongoDB и Redis. Вот только использовать их как БД общего назначения не всегда удобно. Ну и насчет "тупо" - это мимо, однозначно.

Если для ваших задач лучше исполнимый код, никто не против его использования. Я указал на некорректность сравнения скорости работы несопоставимых решений, а не агитировал использовать NoSQL.

все выше было описано - вы возможно читаете не внимательно.

так и я вроде отметил что это частная задача - подсчет объединений и пересечений множеств.

причем тут БД общего назначения? я уже несколько раз повторял что задача частная. которая сначала была решена через SQL-запросы.
далее переведена тупо в обработку готового массива данных.
к примеру для обработки изображений тоже будете CouchDB, MongoDB и Redis использовать?

1. Это не делает корректным сравнение указанного подхода с MySQL
2. То, что Вы отметили в начальном сообщении - "набор данных по сути список подготовленных массивов по которым делается проход и всяческие объединения или пересечения", это слишком маловразумительно для того, чтобы аппелировать к этому.

Да. Я обрабатывал картинки с их помощью. Вопрос в том, что понимать под обработкой, безусловно.