Точка сбора NoSQL

    Приветствую!

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

    Хабраюзеров, писавших на эту тему, я прошу переносить свои топики. Блог понемногу наполняется и ждет ваших новых интересных статей — MongoDB, CouchDB, Cassandra, Redis, Cache — все, что угодно.

    Добро пожаловать!
    Поделиться публикацией

    Комментарии 45

      +2
      я ежедневно работаю с MongoDb и Redis(через редиску)
      Было бы интересно читать материалы на эту тему.
        +1
        Я думаю, с ежедневной работой вы и сами можете поделиться опытом :).
          0
          ну если кто то начнет дискуссию я мог бы=))
            +1
            начинаю!

            кто пробовал Django + MongoDB?
              0
              я не пробовал, но думаю что особой разницы нету.
                0
                Я пробовал RoR + MongoDB, когда она еще падала. Теперь сидим на CouchDb и ничего нам пока* больше не нужно.
                  0
                  А map-reduce вы используете?
                    0
                    Активно изучаем :)
                    А пока обходимся обычными view-функциями с одним map.
                    0
                    какую orm юзали?
                      0
                      CouchRest
                    0
                    Пробовал с хранилищем гугловским (используется один форк Django-nonrel). Главный минус (для меня) — не работает join и many-to-many. То есть для большинства приложений тупо заменить БД не получится
                      0
                      Что вы имеете в виду под «не работает»?
                        0
                        ManyToManyFields не поддерживается, как именно это выражается, если честно, не помню: пока отказался от джанго после нескольких экспериментов — фреймворк выбрать для GAE можно, сменить хранилище нельзя
                      0
                      я пробовал и очень успешно.
                      для front-end'а, скажем так, вполне достаточно pymongo
                      для «админки», а точнее удобной работы по добавлению/обновлению и т.д. рекомендую mongokit
                        0
                        а как со стабильностью?
                        как с основными плюшками админки с монгокитом?
                        где почитать саксесс стори?
                          0
                          >а как со стабильностью?
                          со стабильностью проблем не было, да и нагрузок не было т.к. в локалке компании (CRM-система) и пользуется не много народу.
                          под «админкой» я имею ввиду часть сайта где требуется работа по изменению данных, в этом случае удобно работать с записями как с моделями, со своей схемой, для валидации, с интерфейсами, что и дает mongokit.
                          >как с основными плюшками админки с монгокитом?
                          непосредственно модулем админки джанги я мало пользовался, а для nosql он вроде до сих пор не портирован, хотя я видел проскакивали новости по переводу джанги на nosql.
                          >где почитать саксесс стори?
                          давно специально не искал, но на момент моей работы с этой связкой (месяца 4 назад) с документацией было очень плохо, не говоря уже про статьи, кроме оф. документации к pymongo и mongokit ничем не пользовался, там достаточно просто.

                            0
                            ясно, свой велосипед…
                            было бы неплохо всетаки статейку забацать, а то документации впринципе, кроме сорцов некоторых энтузиастов я тоже не видел
                +1
                Я б перенес, но боюсь, что Cache не подходит под этот блог :)
                  0
                  Ну с т.з. нереляционности вполне подходит :). Или я ошибаюсь?
                    0
                    Cache — ООБД, но с поддержкой SQL :)
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        Да я уже все равно перенес :)
                • НЛО прилетело и опубликовало эту надпись здесь
                    +13
                    — Так у нас проблемы с производительностью, надо добавить кэширование, вертикальное партиционирование и NoSQL DB для логинов.
                    — Парни — я тут посмотрел EXPLAIN — у Вас fullscan запрос на 4,000 строк, я попробовал создать индекс — все ускорилось в 26 раз.

                    via
                      –2
                      Шуточный бот, выдающий комментарии по ключевым словам?
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        Автор забыл упомянуть в тегах RavenDB.
                          +1
                          Если все упоминать, тегов не хватит наверное :)
                            0
                            О, отличная схемка, спасибо.
                              0
                              Я её себе перерисовал на A4 и отмечаю те которые уже попробовал :) Ну и пометки оставляю типа «требует Java», «работает с Thrift» и т.д.
                          +1
                          Только сегодня с нашим админом sql 2000 обсуждали тему nosql.
                          Очень хотелось бы почитать статьи…
                          Сами занимается автоматизацией и учетом ж/д перевозок на очень большом предприятии.
                            0
                            Ну вроде бы в вашем случае реляционные базы данны самое оно. Зачем же там NoSQL?
                              +1
                              Просто интересно! :)
                                +1
                                Просто интересно! :)
                              +1
                              Хотелось бы увидеть сравнение (ключевые отличия друг от друга) «MongoDB, CouchDB, Cassandra, Redis, Cache — все, что угодно» между собой. Сейчас вот начал изучать MongoDB, но выбрал её среди других NoSQL, лишь потому что, как говорится, «на слуху» название.
                                0
                                Это все весьма разные штуки. Как-то можно сравнить между собой mongo и couch, cassandra и riak, всякие базы графов. А по сути важен вопрос — какой тип данных предполагается? Ведь вполне может оказаться, что вам mysql прям очень в тему ;-)
                                Для прототипирования я бы взял mongo — самое простое и функциональное в то же время. Для важных данных я бы монго не выбрал. Так что если вам что-то серьезное хранить — это не ваш выбор.
                                  0
                                  Ну я особо не в теме, только начал изучать нереляционные СУБД (читай — NoSQL), противопоставление mongo и couch как-то встречается, я и подумал что все они одного поля ягоды :)

                                  MySQL точно не в тему, предполагается большое количество объектов с заранее неописанной структурой, общее у них только id, name, description, author и т. п. То есть в случае SQL сразу надо создавать таблицу атрибутов объектов, определять их тип, и, если он не элементарный (ссылка на другие объекты или их списки), производить рекурсивные запросы, да ещё и в цикле в случае списков. Реализовывать это чисто на SQL мне кажется неразумным даже пытаться (если вообще это возможно), устраивать спагетти из SQL и «главного» ЯП не хочется, не говоря о том, что быстродействие всего этого внушает серьёзные опасения.

                                  Но данные как бы важные, юзерам не понравится, если их усилия по заполнению анкеты или написанию поста в блог пропадут :)
                                    0
                                    MySQL точно не в тему, предполагается большое количество объектов с заранее неописанной структурой, общее у них только id, name, description, author и т. п.

                                    Да, это имхо сразу исключает использование РБД: либо замучаетесь с обновлением структуры базы, либо придется создавать кучу избыточных колонок.

                                    Судя по комменту, ссылка на который приведена ниже, стоит попробовать CouchDB.
                                  0
                                  Вот здесь был очень хороший комментарий.
                                  Мы выбрали CouchDb за то что она работает по протоколу Json (простота интеграции с базой, не требующая обязательного использования доп. библиотек)
                                    0
                                    О, что-то вроде этого и имел в виду. Спасибо за наводку :)
                                      0
                                      Минусы-то обосновывйте. У нас помимо сайта несколько модулей на c, для некоторых из которых доп. зависимости нежелательны.
                                      0
                                      Я сравнивал, но в основном для себя, просто попробовать.
                                        0
                                        Сам нашёл habrahabr.ru/blogs/nosql/77909/ :)
                                        0
                                        интересно было бы узнать об опыте использования и про отзывы
                                          0
                                          рано нажал…
                                          про HyperGraphDB и Neo4J

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое