Я занимаюсь, но у меня в статусе и так написано, что я быдло кодер :)

Не забудь на проде autoIndex выключить.

Ну, тут ничего особенного, но я бы предпочёл иметь SQL подобный язык запросов, как в OrientDB.

Mаxmaxmаximus, слушай, а расскажи как ты парсер js писал, как он работает?

Библиотеки для работы с JS: парсинг, валидация, преобразование в AST и обратно в код:

esprima + estools;

babel (babylon);

acorn

Библиотеки для написания парсеров:

jison (аналог Bison, его использует CoffeeScript)

bison

***

Если интересует сам принцип парсинга - то это посимвольный обход строки и формирование последовательностей токенов (лексем), затем на основе лексем строится AST, в котором учитываются приоритеты операторов, уровни вложенности и т.д. Затем работа идёт с АСТ, а после всех преобразований из АСТ мы генерим нужный нам код (будь то js, байткод, LLVM и т.д.).

Хотя это примитивное описание, т.к. алгоритмов парсинга и построения AST существует несколько, например низходящий или восходящий и т.д. Для уточнения этих нюансов лучше читать специальную литературу :)

По советуешь что-то конкретное ?

kobezzza, спасибо)

Я знаю что графовые быстрее и все такое, они как реляционные но как документные в общем самы лучшие базы данных в мире) но я решил начать с монго типа как с популярной. Отлично что ты это посоветовал, ни что не мешает под капот потом её запихнуть. Блин а то что она на яве это же плохо? Да и вообще она умеет распределяться? В смысле на многих узлах работать как монго.

Orient это графы + документо-ориентированная (как монга) - т.е. это комбинированная СУБД. Но вообще "лучших" баз не бывает и нормальный кейз, когда в проекте юзается 2-3 СУБД, например: PostgeSQL (основная субд) + Redis (для горячего кеша) + ElasticSearch (самый лучший полнотекстовый поиск) + Neo4J (графы).

Лучше всего масштабируются столбцовые базы, например, Cassandra от Facebook.

Почитай Фаулера NoSQL и многое станет более понятно.

Половина топовых СУБД написаны на Яве. Не переживай.

Да, есть схожий с монго механизм из коробки. А вообще странный вопрос, ибо любую СУБД можно масштабировать (ну разве что с графами не получится), просто не везде есть механизм "из коробки". А вообще я как то был на мастер классе от TopFace, так они уверяли, что их система масштабирования гораздо эффективнее коробочной их СУБД, в принципе нет причин им не верить :) Но конечно написание своей системы масштабирования - геморой :)

А чому не сделают универсальную БД в которой ты просто будешь говорить вот тут у меня табличка, а вот тут коллекция графов, а вот тут реляционная табличка)? и чел будет выбирать тот способ хранения инфы который лучше подойдет к его данным. И просто придумать универсальный интерфейс взаимодействия с даными всех форм и размером, ну чтобы при запросе можно было и реляционную табличку подгрузить, и сразу её наполнить в документоориентированном стиле и все такое. М?

п.с. да да, ты уже понял что я вношу в список дел сделать такую базу)))

Пытаются. В тот же постгрес добавили документы. Или Orient - графы и документы + интегрированная Lucene (это движок elastic search, но без фич эластика) Топовые реляхи, такие как MS SQL Server и Oracle тоже добавляют фичи из NoSQL баз и т.д.

Но реальность такова, что пока отдельные решения лучше комбайнов. Например многие СУБД умеют полнотекстовый поиск, но они даже близко не подошли к возможностям ElasticSearch. Мб лет через 10-20 комбайны станут нормальными :)