Хабрахабр: коллективные

27.01.2010 10:08:45 YSPRO

YSPRO — Wed, 27 Jan 2010 10:08:45 GMT

ясн, 24-байтный HEX конвертится в 12-байтный BIN

27.01.2010 10:02:31 YSPRO

YSPRO — Wed, 27 Jan 2010 10:02:31 GMT

>В качестве уникального идентификатора используется не auto-increment'ное поле, а 12-байтное уникальное число, генерируемое на клиенте.

А может 24-байтное?

06.11.2009 15:23:51 ingeniarius

ingeniarius — Fri, 06 Nov 2009 15:23:51 GMT

Нереалиационные БД хороши и быстры,
однако реалицонность можно сделать нормально только с РСУБД.
Хорошо что есть и те, и те :)
А ещё лучше то, что есть такие как MySQL и TokyoCabinet

06.11.2009 15:13:43 latrommi

latrommi — Fri, 06 Nov 2009 15:13:43 GMT

(отписал в личку)

06.11.2009 15:00:16 TravisBickle

TravisBickle — Fri, 06 Nov 2009 15:00:16 GMT

А второй запуск?

06.11.2009 14:22:57 latrommi

latrommi — Fri, 06 Nov 2009 14:22:57 GMT

Сделал как вы сказали, прописал:

mongo = mongo_db.collection(«beta»)
mongo.remove

и всё равно:

$ ruby mymongo.rb 
      user     system      total        real
mysql:  0.300000   0.100000   0.400000 (  1.754915)
mongodb:  5.910000   0.230000   6.140000 (  6.880819)

:-/

06.11.2009 13:42:07 TravisBickle

TravisBickle — Fri, 06 Nov 2009 13:42:07 GMT

Коллекция в Mongo создается не при вызове mongo = mongo_db.collection(«beta»), а при первом вызове mongo.insert(doc). Ну и по умолчанию в Mongo большой pre-allocation места для коллекции, так что грубо говоря 4.999 создавался пустой файл размером порядка 2.5 гб (зависит от свободного места на разделе), а остальные 0.001 делались полезные операции.
Создайте пустую коллекцию изначально, а потом протестируйте ;-) В init достаточно делать «mongo.remove».

06.11.2009 12:00:15 latrommi

latrommi — Fri, 06 Nov 2009 12:00:15 GMT

Сама БД клёвая, и я как-то тестировал ее, но, почему-то, получилось медленнее MySQL:
blog.knopkodav.ru/2009/10/mongodb-vs-mysql.html

Специально ни тот ни другой не настраивал, всё, можно сказать, из коробки.
Что тут не так?

06.11.2009 06:58:52 xmcdbx

xmcdbx — Fri, 06 Nov 2009 06:58:52 GMT

вот за это даже руку пожму. а то у меня уже всё на SQL-запросах, а сейчас очень нужны фишки Монго)

05.11.2009 16:24:30 ptiss

ptiss — Thu, 05 Nov 2009 16:24:30 GMT

о, живой опыт людей всегда интересен. Сейчас как раз присматриваюсь к подобным БД (Couch и Mongo), нет ли в планах статьи на тему?
И тогда по CouchDB сразу вопрос — а запросы в виде материализованных видов не напрягают? Каждый раз их определять на мой взгляд несколько муторно по сравнению с приснопамятным SQL или запросами к Mongo.

05.11.2009 14:24:12 el777

el777 — Thu, 05 Nov 2009 14:24:12 GMT

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

05.11.2009 14:17:30 el777

el777 — Thu, 05 Nov 2009 14:17:30 GMT

> есть такая страшная штука Zope
Воистину страшная!
После работы с этим чудом инженерной мысли я с большим предубеждением воспринимаю все «самопальные» (то есть не имеющие ~100К серьезных внедрений) базы данных. Как почитаешь про ZODB так все выглядит очень гладко, но на практике как обычно «забыли про овраги». При росте базе (всего ~10K записей) начались серьезные тормоза, кроме того база, заявленная как очень надежная, постоянно сыпалась почище myisam, хуже того — средств восстановления для нее нет.
После работы с этим зопом я понял почему его так назвали.
А «геморрой — это зопяная боль».

04.11.2009 13:34:43 TravisBickle

TravisBickle — Wed, 04 Nov 2009 13:34:43 GMT

Для домашней странички можно использовать что угодно, однако я лично не вижу чем работа с Mongo сложнее написания SQL-запросов, в чем-то даже проще. Проектировать значительно проще, поскольку не надо думать о схеме и об изменениях в ней. В MySQL и иже с ним меня сильно демотивирует что каждый раз надо поле ручками добавлять или менять его тип.
Да, термин мой, просто на мой взгляд, она и не объектная (это все же немного другое) и не документарная (не BigTable). Кстати я планирую написать парсер SQL-запросов и конвертатор в Mongo-запросы на лету: то есть просто подключаете этот слой и делаете например SELECT * FROM collection WHERE x > 1 AND y < 5. По большому счету ничего сложного.

04.11.2009 06:35:50 VolCh

VolCh — Wed, 04 Nov 2009 06:35:50 GMT

Но всё-таки основные преимущества в hi-load проектах и чисто по быстродействию в условиях масштабирования и множественных добавлений и изменений? Как насчёт простоты (особенно привыкшим к реляционным БД, не обязательно SQL ;) ) проектирования и реализации на уровне серверов приложений, что в «голом» SQL, что по сравнению с ORM «прокладками»? В общем «серебряная пуля» или нужно досконально знать все плюсы и минусы разных альтернатив, хотя бы на уровне ORM vs «объектно-документарная база данных» (не знаю как написать на инглише — гугл и рамблер дают ссылку только на этот топик — термин ваш лично? )

04.11.2009 06:11:36 VolCh

VolCh — Wed, 04 Nov 2009 06:11:36 GMT

Автор, имхо, немного неправильный порядок употребил. Логично или «таблицы, SQL, MySQL» (академический взгляд), или прямо наоборот (практический).

04.11.2009 05:58:25 VolCh

VolCh — Wed, 04 Nov 2009 05:58:25 GMT

Может из желания поддержать «многие вещи»? :)

03.11.2009 23:56:11 TravisBickle

TravisBickle — Tue, 03 Nov 2009 23:56:11 GMT

Sharding Introduction
Это тема второй, более подробной статьи на эту тему. Там я рассмотрю все эти аспекты вполне детально.

03.11.2009 23:50:01 max_m

max_m — Tue, 03 Nov 2009 23:50:01 GMT

> либо делать партишенинг таблиц, разбивая таблицу на несколько частей и храня их в разных местах,
> согласно заданному закону (например по ID), однако это унесет в могилу прелести JOIN

А как эта проблема решена в монго? Он позволяет сделать некий JOIN данных между разными шардами?

03.11.2009 19:17:50 creotiv

creotiv — Tue, 03 Nov 2009 19:17:50 GMT

это если не нужно хранить записи.

общение риал тайм писал на Си как демон… это да. Но если надо потом что то еще делать с данными то без БД не обойтись.

Вообщем как я ни раз говорил все зависит от ситуации…

03.11.2009 19:16:18 rukeba

rukeba — Tue, 03 Nov 2009 19:16:18 GMT

а ещё MongoDB может работать как database backend для Django — bitbucket.org/kpot/django-mongodb/

03.11.2009 19:09:35 ibeatle

ibeatle — Tue, 03 Nov 2009 19:09:35 GMT

ага) особенно после слов «резкая как понос» ))

03.11.2009 18:53:47 TravisBickle

TravisBickle — Tue, 03 Nov 2009 18:53:47 GMT

Оффтоп, но чаты лучше писать с использованием RTEP (phpDaemon), без БД. Т.е. роутить события сразу, а не кидать в БД и потом проверять.
Скоро выложу чат который держит сотни тысяч пользователей одновременно, как ejabberd прям :-)

03.11.2009 18:50:01 creotiv

creotiv — Tue, 03 Nov 2009 18:50:01 GMT

раньше крутил редисДБ… были свои прелести, типа там чаты, и очереподобные творения… а тут такая интересная штука… вот думаю куда бы приструнить что б потестить)

03.11.2009 18:48:32 TravisBickle

TravisBickle — Tue, 03 Nov 2009 18:48:32 GMT

Значит, я добился своей цели :))

03.11.2009 18:40:12 creotiv

creotiv — Tue, 03 Nov 2009 18:40:12 GMT

Вы так написали, что срочно захотелось ее скачать и позырить))

03.11.2009 17:58:33 asm0dey

asm0dey — Tue, 03 Nov 2009 17:58:33 GMT

А вот меня Firebird Интересует…

03.11.2009 17:35:56 TMC

TMC — Tue, 03 Nov 2009 17:35:56 GMT

А как повысить лимит без проблем? В официальной гуглгруппе создатели ничего такого не говорили…

03.11.2009 16:32:45 TravisBickle

TravisBickle — Tue, 03 Nov 2009 16:32:45 GMT

Я скажу банальщину, но пользователи нагружают, им этого не объяснишь. Ведь мы явно не в шину упрёмся. Я и не говорю про обработку, я говорю о get/set/increment.

03.11.2009 16:29:30 TravisBickle

TravisBickle — Tue, 03 Nov 2009 16:29:30 GMT

Во-первых лимит можно повысить, во-вторых можно ID сообщений хранить в объекте, а тексты хранить в отдельной коллекции. Т.е. мы выдергиваем первым запросом нужную нам структуру, а затем уже выдергиваем одним запросом все нужные тексты, это даже быстрее будет работать, т.к. структура со ссылками на тексты будет совсем простая. Это нормальная практика — хранить дерево отдельно от данных.

03.11.2009 16:16:14 point

point — Tue, 03 Nov 2009 16:16:14 GMT

Ради простоты внутренней архитектуры и быстродействия было решено сделать редис однопоточным. Он простой в понимании => простой в применении.

С другой стороны, непонятно, зачем нагружать редис так, что нужны все 8 ядер? Этоже kv- _store_. Т.е. основное предназначение сохранять данные, а обрабатывать их должно приложение, которое уже может работать на нескольких потоках.

03.11.2009 16:01:53 sabay

sabay — Tue, 03 Nov 2009 16:01:53 GMT

Были и есть более удачные реализации многомерных БД (и построенной поверх них объектности), к примеру www.cache.ru/
да она коммерческая — но уже десятки лет ( а точнее раньше самой каше ) были и есть M системы ( а каше ей и является )
и были умники которые говорили что реляционки теперь не нужны — сам был среди них.
а теперь оглянитесь и посмотрите на чем сделана большая часть проектов.

03.11.2009 15:57:58 TravisBickle

TravisBickle — Tue, 03 Nov 2009 15:57:58 GMT

На MySQL. А откуда спрашивается пролежни так часто?)))

03.11.2009 15:43:26 angry_elf

angry_elf — Tue, 03 Nov 2009 15:43:26 GMT

Можно хранить комменты отдельной сущностью и подтягивать вместе с постом одним запросом (это я про couchdb). Работать это будет исключительно быстро. Создание комментов ничего блокировать не будет, race condition тоже вызвать не получится.

03.11.2009 15:43:16 TMC

TMC — Tue, 03 Nov 2009 15:43:16 GMT

Лимиты про 2Гб — это из-за использования mmap. К размеру ОЗУ отношения не имеет.

03.11.2009 15:33:41 TravisBickle

TravisBickle — Tue, 03 Nov 2009 15:33:41 GMT

Для того чтобы выжрать ресурсы Quad Xeon'а автор предлагает запустить 8 редисок и балансировать между ними по ключам:-)

03.11.2009 15:22:40 point

point — Tue, 03 Nov 2009 15:22:40 GMT

> Redis однотредовый
И что с этого? Там используется асинхронный способ работы с данными

03.11.2009 15:16:41 angry_elf

angry_elf — Tue, 03 Nov 2009 15:16:41 GMT

Подробности раскрывать не могу, опишу общими словами.
Есть несколько потоков, читающие и пишущие в базу.
Структура базы — две таблицы. Одна — список сущностей (около 200.000 на тот момент было). Вторая — история обработки сущностей (около миллиона).
Потоки брали сущности из базы (select from table1), блокировали их (update table1), какое-то время работали с ними, дописывали во вторую таблицу логи (insert into table2), потом обновляли состояние сущности (update table1) на основании истории (select from table2).

Пока использовался mysql, больше 6-8 запустить было невозможно, mysql отъедал одно ядро полностью и дальше не давал рости.
Был так же web-interface для просмотра статистики, запросы на котором (2-3 запроса по хорошим ключам) отрабатывали секунд по 20. С него так же генерилось небольшое количество insert/update (порядка 1-2 в минуту), которые так же отрабатывали с дикими тормозами.

В случае с couchdb, его не видно в top, процессов запущено около 30, они грузят полностью 4 ядра и больше потестировать не могу. При этом, база выросла в несколько раз (количество сущностей — около 1.700.000).
Организована couchdb так: один документ — одна сущность из table1, у каждой из них история в виде списка в одном из полей.
Веб-интерфейс теперь отрабатывает мгновенно.

03.11.2009 15:08:38 CAH4A

CAH4A — Tue, 03 Nov 2009 15:08:38 GMT

А сам Хабр разве не на MySQL работает?

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