nosql

[Антон]

доброго времени суток
очень надеюсь на вашу помощь, подскажите nosql решение для наименее
безболезненного перехода с mysql. сейчас в проекте есть пара хитрых
запросов с union + join, в остальных запросах ничего особенного

[Haspadar]

Для чего?

HandlerSocket?

2011/12/23 Антон <aqw....@gmail.com>

[Денис Кириченко]

MongoDB решает! :)
используем в продакшине при нагрузке в 10000 уников в день..
Очень легко масштабируется.. а когда переходишь с мускула на него... то потом не понимаешь, как вообще с мускулом работал до этого :))

23 декабря 2011 г. 20:05 пользователь Haspadar <hasp...@gmail.com> написал:

--
С уважением, Денис Кириченко.

[Антон]

подскажи , сам писал бибилоитеку для работы с MongoDB или готовую
выбрал (какую)?

On 23 дек, 14:09, Денис Кириченко <zedroxy...@gmail.com> wrote:
> MongoDB решает! :)
> используем в продакшине при нагрузке в 10000 уников в день..
> Очень легко масштабируется.. а когда переходишь с мускула на него... то
> потом не понимаешь, как вообще с мускулом работал до этого :))
>

> 23 декабря 2011 г. 20:05 пользователь Haspadar <haspa...@gmail.com> написал:
>
> > Для чего?
>
> > HandlerSocket?
>
> > 2011/12/23 Антон <aqw.no...@gmail.com>

[Антон]

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

On 23 дек, 13:05, Haspadar <haspa...@gmail.com> wrote:
> Для чего?
>
> HandlerSocket?
>

> 2011/12/23 Антон <aqw.no...@gmail.com>

[Денис Кириченко]

Есть много готовых. Но если честно, после изучения всех библиотек, пришел к выводу, что нужно написать свои классы просто отнаследованные от стандартных классов экстеншена для монго под php. Основной сутью которых есть отдача результата поиска по данным в базе в виде Обьектов опреденного типа, а не в виде просто данных. Тем более, что монго - это обьектно-ориентированная база. Ее как раз для этого идеально использовать.
Собственно врапперы свои приметивнейшие.. поэтому не будет проблем рабобраться и написать свои. или испотльзовать наши как за основу.
Как из фишек чисто наших это:

• Ik_Mongo::getCollection() - банальный глобальный контейнер, через который получаются обьекты коллекций, потому как смысл каждый раз создавать обьект типа MongoCollection или даже Zend_Db_Table нету в 99% случаев, а прирост по скорости очень существенный. Этот подход так же действует и при Zend_Db_Table..
• Ik_Mongo_Collection->findDocs() - собственно основной метод ради которого писались обвертки. Возвращяет данные в виде обьектов. + реализует кеширование на уровне выборки по _id. Прирост по скорости существенный.
• Ik_Mongo_Document->getData() - реализует получение свойства из обьекта по любому ключу с любой вложенностью массива данных обьекта. Например: $user->getData('personal.address.street.house') выберает из $user->_data['personal']['address']['street']['house'].
• А так же Ik_Mongo_Document->getData() использует getI18nData для получения мультиязычных данных. Очень приятная фишка.. в базе мы просто храним такой обьект например:

{
  "ancestors": [
    ObjectId("4d41607b8f2a2d8408040000"),
    ObjectId("4cfa7167e56645b80a000000")
  ],
  "createdAt": ISODate("2011-01-27T12:11:28.0Z"),
  "createdBy": "denis",
  "mods": {
    "menuItem": {
      "type": "self"
    },
    "page": {
      "path": "klientam\/najti_platezh",
      "status": 2,
      "title": [
        {
          "l": "ru",
          "v": "Найти платеж"
        },
        {
          "l": "en",
          "v": "Find payment"
        },
        {
          "l": "uk",
          "v": "Знайти оплату"
        }
      ]
    }
  },
  "type": "page"
}

И Ik_Mongo_Document->getData() просто смотрит в выбераемые данные. определяет их как мультиязычные в случае если там есть конструкция типа:[{"l": "?", "v": "?"}] и возвращает их отталкиваяьб от услановленной локали (языка).

Пример работы:
$paysystemCollection = Ik_Mongo::getCollection('Ik_Paysystem_Collection');
$paysystem = $paysystemCollection->findDoc(array('system.alias' => 'webmoney'));
$name = $paysystem->getData('name');
echo $name; // Вебмани

24 декабря 2011 г. 6:53 пользователь Антон <aqw....@gmail.com> написал:

[Антон]

спасибо! а как вы обходите сложные запросы с join, union, in

On 25 дек, 05:58, Денис Кириченко <zedroxy...@gmail.com> wrote:
> Есть много готовых. Но если честно, после изучения всех библиотек, пришел к
> выводу, что нужно написать свои классы просто отнаследованные от
> стандартных классов экстеншена для монго под php. Основной сутью которых
> есть отдача результата поиска по данным в базе в виде Обьектов опреденного
> типа, а не в виде просто данных. Тем более, что монго - это
> обьектно-ориентированная база. Ее как раз для этого идеально использовать.
> Собственно врапперы свои приметивнейшие.. поэтому не будет проблем
> рабобраться и написать свои. или испотльзовать наши как за основу.
> Как из фишек чисто наших это:
>

>    - Ik_Mongo::getCollection() - банальный глобальный контейнер, через

>    который получаются обьекты коллекций, потому как смысл каждый раз создавать
>    обьект типа MongoCollection или даже Zend_Db_Table нету в 99% случаев, а
>    прирост по скорости очень существенный. Этот подход так же действует и при
>    Zend_Db_Table..

>    - Ik_Mongo_Collection->findDocs() - собственно основной метод ради

>    которого писались обвертки. Возвращяет данные в виде обьектов. + реализует
>    кеширование на уровне выборки по _id. Прирост по скорости существенный.

>    - Ik_Mongo_Document->getData() - реализует получение свойства из обьекта

>    по любому ключу с любой вложенностью массива данных обьекта. Например:
>    $user->getData('personal.address.street.house') выберает из
>    $user->_data['personal']['address']['street']['house'].

>    - А так же Ik_Mongo_Document->getData() использует getI18nData для

> 24 декабря 2011 г. 6:53 пользователь Антон <aqw.no...@gmail.com> написал:

>
>
>
>
>
>
>
>
>
> > в будущем предполагается большой объем данных и это беспокоит в плане
> > масштабирования. пока данных практически нет - проект на начальной
> > стадии
>
> > On 23 дек, 13:05, Haspadar <haspa...@gmail.com> wrote:
> > > Для чего?
>
> > > HandlerSocket?
>
> > > 2011/12/23 Антон <aqw.no...@gmail.com>
>
> > > > доброго времени суток
> > > > очень надеюсь на вашу помощь, подскажите nosql решение для наименее
> > > > безболезненного перехода с mysql. сейчас в проекте есть пара хитрых
> > > > запросов с union + join, в остальных запросах ничего особенного
>
> --
> С уважением, Денис Кириченко.
>

>  Mongo.zip
> 10KПросмотретьЗагрузить

[Денис Кириченко]

тут необходимо вам понять и освоить саму методологию проектирования и разработки под ООП базы данных. ТАм вообще нет такого понятия как джоины (union). Там обьекты храняться в своих коллекциях и могут ссылаться на другие обьекты.
Можете погуглить и просто ознакомится с типовым решением различных задач и ознакомится с самой БД:
http://habrahabr.ru/blogs/nosql/74144/
http://habrahabr.ru/blogs/MongoDB/134590/
http://habrahabr.ru/blogs/nosql/74273/
http://habrahabr.ru/blogs/nosql/119703/

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

25 декабря 2011 г. 14:33 пользователь Антон <aqw....@gmail.com> написал:

[Oleg Lobach]

25.12.2011 03:58, О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫:
> О©╫О©╫О©╫О©╫О©╫ - О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫

О©╫О©╫О©╫О©╫О©╫ - О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫ - О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫.

[Денис Кириченко]

согласен, но для простоты понимания, я назвал ее ООП базой :)
но я могу смело утверждать, что она покрывает 99% необходимого функционала для работы с данными как с обьектами :)

Документоориентированная база данных — компромиссная модель, сочетающая гибкость триплетов с ёмкостью реляционных кортежей.

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

Еще по теме сравнения с MySQL
http://highload.com.ua/index.php/2010/03/02/mongodb-document-oriented-db-and-mysql/

26 декабря 2011 г. 10:24 пользователь Oleg Lobach <lobac...@gmail.com> написал:

25.12.2011 03:58, Денис Кириченко пишет:

монго - это обьектно-ориентированная база

Монга - не ООБД, монга - документ-ориентированная СУБД.

[Oleg Lobach]

26.12.2011 18:09, О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫:
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ :)
> О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ 99% О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ :)

О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ - О©╫О©╫О©╫

О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫