MongoDB

[AlexCooper]

Мой пост не является универсальным решением, и всегда нужно отталкивать от рода задач поставленных на программное обеспечение.
Что конкретно вас интересует? Можно конечно же использовать СОМЕТ-сервер но мне достаточно было использовать протокол передачи данных AMF3 вместе с лонг-пулом где это нужно было.
кратко о лонг-пуле

Добавлено через 2 минуты
Конечно нужно добавить еще репликацию с шардингом но это уже другой вопрос, так как не всегда изначально есть н-серверов.

Добавлено через 1 час 5 минут

Сообщение от Krusty

А, ограничения архитектуры.

Какие ограничения архитектуры?

[kackbip]

Сообщение от Psycho Tiger

В монгоДБ есть индекс. Почему она не нормальная?

Про индекс я протупил.
Основной ее недостаток в отсутствии SQL. Можно более-менее без проблем менять одну СУБД на другую, если они SQL. Но как только нам нужно перейти на NoSQL, тут же приходится переписать все модели. Хотя в ORM в playframework и сделана поддрежка mongodb, но это скорее исключение из правил.

[Krusty]

Вы, видимо, никогда не меняли одну СУБД на другую (замена сама по себе уже свидетельствует о огромном недостатке проектирования, и выбирать что-то на основе SQL только из-за возможности миграции на другой SQL продукт - опять-таки неверно в корне). Если вам кажется, что миграция между oracle, mysql, постгресс и mssql выполняется просто - это заблуждение. Вроде как заменил СУБД, а синтаксис тот же. Совершенно не так.

Добавлено через 6 минут

Сообщение от AlexCooper

Какие ограничения архитектуры?

Не умеет кэшировать некоторые запросы. Логично отсутствие кэша в случае с NOW(), например. Отсутствие кэширования на сложных join - это именно ограничения самого mysql - нет никаких теоретических ограничений, что бы это реализовать.

[kackbip]

Вы, видимо, никогда не меняли одну СУБД на другую (замена сама по себе уже свидетельствует о огромном недостатке проектирования, и выбирать что-то на основе SQL только из-за возможности миграции на другой SQL продукт - опять-таки неверно в корне). Если вам кажется, что миграция между oracle, mysql, постгресс и mssql выполняется просто - это заблуждение. Вроде как заменил СУБД, а синтаксис тот же. Совершенно не так.

Да я вобще профан в этом деле. Дискутирую ради получения опыта

Но все таки возразу:
1) Если вы создаете некий модуль или фреймворк, то почему бы не реализовать совместимость с разными СУБД?
2) Если вы выбираете SQL, то у вас по-крайней мере будет возможность легкой миграции. У каждой NoSQL же интерфейс свой особенный.
3) В чем заключается сложность миграции с одной sql субд на другую? За исключением нюансов, большая часть запросов скорее всего не изменится.

[AlexCooper]

Сообщение от Krusty

Вы, видимо, никогда не меняли одну СУБД на другую (замена сама по себе уже свидетельствует о огромном недостатке проектирования, и выбирать что-то на основе SQL только из-за возможности миграции на другой SQL продукт - опять-таки неверно в корне). Если вам кажется, что миграция между oracle, mysql, постгресс и mssql выполняется просто - это заблуждение. Вроде как заменил СУБД, а синтаксис тот же. Совершенно не так.

Добавлено через 6 минут

Не умеет кэшировать некоторые запросы. Логично отсутствие кэша в случае с NOW(), например. Отсутствие кэширования на сложных join - это именно ограничения самого mysql - нет никаких теоретических ограничений, что бы это реализовать.

На данном этапе миграция происходит успешно, так как получилось организовать структуру в nosql базе так как было очень затратно а mysql. Да конечно не просто взять и перенести все, но оно себя оправдывает.
Посмотрите на структуру.

В MySQL для реализации подобного нужно было создавать три отдельных таблицы (картинки, лайки, комменты) и при получении информации нужно было делать выбор по всем трем таблицам плюс строковые обработки. В MongoDB все гараздо проще и поиск происходит в разы быстрее. Причём скажу что кэш монго работает на отлично, подтверждаю тем что результат одного и того же запроса выполняется с ускорением в 2-3 раза. (тесты).

Добавлено через 14 минут
Не могу не согласиться с тем что были проблемы в проектировании но над проектом работаем с прошлых бря-месяцев и сам проект уже видоизменялся н-количество раз. На ряду с увеличением нагрузок решили перенести проблемные места на монго. Теперь у нас получилась комбинированная система с MySQL и NoSQL базой данных.

p.s. to be continue... =)

[Psycho Tiger]

Сообщение от kackbip

Про индекс я протупил.
Основной ее недостаток в отсутствии SQL. Можно более-менее без проблем менять одну СУБД на другую, если они SQL. Но как только нам нужно перейти на NoSQL, тут же приходится переписать все модели. Хотя в ORM в playframework и сделана поддрежка mongodb, но это скорее исключение из правил.

SQL разный у разных СУБД. Придется всё равно переписывать адаптеры или-что-там к этой самой БД, а SQL там или NoSQL особой роли не сыграет.
То есть, по хорошему: в модели должен быть метод select(name:String, value:String), а что он будет формировать -

mongoCollection.find({name: value})

или

sqlBase.execute(select * from table where name=value)

- дело модели.

[PainKiller]

flash->amfphp->mongoDB

А можно про это поподробнее? Сейчас изучаю монгу и появилось желание реализовать эту связку? Но конечно прежде чем писать свой, хотелось бы посмотреть на чужие варианты.

[bifidokk]

Сообщение от PainKiller

А можно про это поподробнее? Сейчас изучаю монгу и появилось желание реализовать эту связку? Но конечно прежде чем писать свой, хотелось бы посмотреть на чужие варианты.

а можно поподробнее рассказать, что вам именно в этой связке непонятно?

[PainKiller]

Мне в этой связке все понятно. Просто интересует вопрос (а проверить руки не дошли) получается ли на стороне явы откастовать приходящий в amf джисон к типу BasicBDObject? Вот на этот код как раз и хотелось бы взглянуть, если получается то это очень и очень круто. Хотя это не принципиально, даже если и не получается, просто придется писать лишний код.

Добавлено через 3 минуты
Но это если говорить про яву. А под влиянием монги, я взялся за Node.js, работать с монгой из явы это немножко извращение, с яваскриптом все значительно проще.