Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 46
MongoDB is a web scale! :)
Этот диалог необходимо смотреть в оригинальном исполнении, чтобы не потерять всех эмоций, которые передают актёры.
mongodb-is-web-scale.com/
mongodb-is-web-scale.com/
<nerd> оригинал всё же — www.gar1t.com/blog/mongo-db-is-web-scale.html </nerd>
С сожалением, пришлось отказаться от Монго, так как он съедал память на моём единственном сервере. А выделенный сервер, это пока слишком жирно. Может есть способы его вернуть?
если жалко выделенный сервер, то, наверное, решаемая задача не «web scale» и достаточно MySQL :)
Есть mongolab.com (500 Mb бесплатно).
Браво, просто таки ошеломляющая победа над «чучелом Mongo».
Очень не люблю фанатиков, и ОСОБЕННО ненавижу фанатиков древних как окаменевшее говно мамонта технологий. Нет, я уже недостаточно молод для "… до основанья, а затем..." и вполне признаю право устаревших технологий на продолжение своего существования, но фанатеть от них?
Так как самым важным (и сложным) в программировании является управление сложностью создаваемых программ, то хороший язык программирования обязан:
1. Предоставлять средства построения абстракций, позволяющие разбивать задачу на относительно независимые подзадачи.
2. Предоставлять выразительные средства наиболее близкие к тому ЧТО хочет программист, а не к полному описанию алгоритма получения искомого результата. Данный пункт во многом перекликается с предыдущим (а в языках, поддерживающих создание синтаксических абстракций, полностью включен в него), но все таки стоит отдельно.
Раньше когда я пытался показать почему мне не нравится SQL, я сравнивал его с фортраном. Сейчас я понимаю, что это сравнение несправедливо по отношению к фортрану. В фортране есть и сложные структуры данных (в том числе вложенные), и функции с неглобальной областью видимости, и массивы (в том числе и многомерные), и итерации над коллекциями (как специализированный сахар, а не как ручное закатывание солнца) и еще много чего.
В SQL мы имеем глобальные процедуры и функции (триггеры и отображения являются специализированными процедурами), из типов данных — пучок примитивных типов данных (нет беззнаковых целых, но есть двоично-десятичные дроби — кто вообще до сих пор считает это хорошей идеей?) плюс таблицы. Все. Это настолько примитивно, что даже некоторые ассемблеры более выразительны.
Очень не люблю фанатиков, и ОСОБЕННО ненавижу фанатиков древних как окаменевшее говно мамонта технологий. Нет, я уже недостаточно молод для "… до основанья, а затем..." и вполне признаю право устаревших технологий на продолжение своего существования, но фанатеть от них?
Так как самым важным (и сложным) в программировании является управление сложностью создаваемых программ, то хороший язык программирования обязан:
1. Предоставлять средства построения абстракций, позволяющие разбивать задачу на относительно независимые подзадачи.
2. Предоставлять выразительные средства наиболее близкие к тому ЧТО хочет программист, а не к полному описанию алгоритма получения искомого результата. Данный пункт во многом перекликается с предыдущим (а в языках, поддерживающих создание синтаксических абстракций, полностью включен в него), но все таки стоит отдельно.
Раньше когда я пытался показать почему мне не нравится SQL, я сравнивал его с фортраном. Сейчас я понимаю, что это сравнение несправедливо по отношению к фортрану. В фортране есть и сложные структуры данных (в том числе вложенные), и функции с неглобальной областью видимости, и массивы (в том числе и многомерные), и итерации над коллекциями (как специализированный сахар, а не как ручное закатывание солнца) и еще много чего.
В SQL мы имеем глобальные процедуры и функции (триггеры и отображения являются специализированными процедурами), из типов данных — пучок примитивных типов данных (нет беззнаковых целых, но есть двоично-десятичные дроби — кто вообще до сих пор считает это хорошей идеей?) плюс таблицы. Все. Это настолько примитивно, что даже некоторые ассемблеры более выразительны.
ну, во-первых, напомню о теге «юмор» :)
я активно использую MySQL лет 9, но SQL-запросы в коде не писал уже несколько лет.
использую их только в консоли, чтобы быстро получить какой-то отчёт или для одноразовых bulk insert/update, когда это быстрее, чем писать скрипт.
поэтому SQL для многих становится действительно аналогом ассемблера: оно есть, но напрямую всё реже пользуются и часто не знают всех тонкостей (плохо, конечно, но опять же — большинству не надо).
MongoDB тоже люблю и использую.
идея очень хороша, много всяких приятностей. но пока есть много недостатков, например, «locks on a per-database basis for most read and write operations» (до 2.2 было ещё хуже — один global lock на весь mongod instance).
поэтому автор прав — большинству хватит и MySQL.
не стоит хвататься за всё модное, если нет желания вникать как оно работает, а просто чувствовать себя в тренде.
я активно использую MySQL лет 9, но SQL-запросы в коде не писал уже несколько лет.
использую их только в консоли, чтобы быстро получить какой-то отчёт или для одноразовых bulk insert/update, когда это быстрее, чем писать скрипт.
поэтому SQL для многих становится действительно аналогом ассемблера: оно есть, но напрямую всё реже пользуются и часто не знают всех тонкостей (плохо, конечно, но опять же — большинству не надо).
MongoDB тоже люблю и использую.
идея очень хороша, много всяких приятностей. но пока есть много недостатков, например, «locks on a per-database basis for most read and write operations» (до 2.2 было ещё хуже — один global lock на весь mongod instance).
поэтому автор прав — большинству хватит и MySQL.
не стоит хвататься за всё модное, если нет желания вникать как оно работает, а просто чувствовать себя в тренде.
я активно использую MySQL лет 9, но SQL-запросы в коде не писал уже несколько лет
А как вы делаете запросы данных на стороне сервера? Как можно написать скрипт заменяющий MySQL запрос?
Ну дык это и не Ваше творение — оригинальный автор похоже не шутил (вернее, скорее всего он считал, что насмехается над «фанатами» Mongo).
Да мепперы спасают до определенной степени (я по возможности пытаюсь выносить запросы в LINQ, оставляя саму базу практически без хранимых процедур), но они лишь явственно очерчивают проблему с SQL, а не решают ее (ну и приносят импеданс, про который упомянул автор, а вернее пару десятков оных). То есть по сути ORM-ы — тоже NoSQL.
От RDBMS остается фактически только хранение B-деревьев, с чем вполне справляются всякие BDB, да и все остальные БД — как SQL так и NoSQL (включая Mongo) используют B-деревья как основную структуру данных для хранения индексов.
Что же до Mongo — да, глобальный лок — ОЧЕНЬ спорное решение изначально, с другой стороны она таки действительно масштабируется горизонтально (и, как Вы отметили, этот самый лок разбивается на несколько — в каждом mongod свой). Ну и отлично понимая, что я — «нерепрезентативная выборка», но в моем личном опыте неосторожное обращение с констрейнтами убило больше производительности, чем глобальный лок в Mongo.
Да мепперы спасают до определенной степени (я по возможности пытаюсь выносить запросы в LINQ, оставляя саму базу практически без хранимых процедур), но они лишь явственно очерчивают проблему с SQL, а не решают ее (ну и приносят импеданс, про который упомянул автор, а вернее пару десятков оных). То есть по сути ORM-ы — тоже NoSQL.
От RDBMS остается фактически только хранение B-деревьев, с чем вполне справляются всякие BDB, да и все остальные БД — как SQL так и NoSQL (включая Mongo) используют B-деревья как основную структуру данных для хранения индексов.
Что же до Mongo — да, глобальный лок — ОЧЕНЬ спорное решение изначально, с другой стороны она таки действительно масштабируется горизонтально (и, как Вы отметили, этот самый лок разбивается на несколько — в каждом mongod свой). Ну и отлично понимая, что я — «нерепрезентативная выборка», но в моем личном опыте неосторожное обращение с констрейнтами убило больше производительности, чем глобальный лок в Mongo.
> То есть по сути ORM-ы — тоже NoSQL.
С какой это стати? Типичная ORM-выборка по связанным объектам транслируется в пачку джойнов. Да что там, в том же LINQ джойны даже явно фигурируют. И транзакции и прочее тоже вполне SQL-подобны.
С какой это стати? Типичная ORM-выборка по связанным объектам транслируется в пачку джойнов. Да что там, в том же LINQ джойны даже явно фигурируют. И транзакции и прочее тоже вполне SQL-подобны.
Ну, прежде всего, в ORM-ах нет реляционной алгебры (по крайней мере на объектном конце — именно поэтому нужен «меппинг»).
Если же говорить конкретно про LINQ, то join-ы в нем семантически больше похожи на таковые в XQuery: декартово произведение сущностей с фильтрацией зависимых (вместо генерации нового множества кортежей со значениями). То что некоторые LINQ провайдеры генерируют на выходе SQL — отнюдь не означает, что LINQ это и есть SQL (просто с другим синтаксисом) — между ними семантическая (а не синтаксическая — как раз синтаксис относительно близок) пропасть.
То есть образно говоря, LINQ настолько же не SQL, насколько, например, C++ — это не машинный код.
Если же говорить конкретно про LINQ, то join-ы в нем семантически больше похожи на таковые в XQuery: декартово произведение сущностей с фильтрацией зависимых (вместо генерации нового множества кортежей со значениями). То что некоторые LINQ провайдеры генерируют на выходе SQL — отнюдь не означает, что LINQ это и есть SQL (просто с другим синтаксисом) — между ними семантическая (а не синтаксическая — как раз синтаксис относительно близок) пропасть.
То есть образно говоря, LINQ настолько же не SQL, насколько, например, C++ — это не машинный код.
ORM — NoSQL формально, но всё равно RDBMS.
Нет, реляционной алгеброй в ORM-ах не пахнет. Все операторы реляционной алгебры отображают кортежи в кортежи. Любая агрегация (в смысле включения одних объектов и коллекций в другие, а не свертка набора значений в одно) — это уже очень существенно нереляционно (собственно говоря, это один из тех самых «impedance mismatch»-ей: O-часть ORM-а работает над графом зависимостей, а R-часть — над множествами кортежей).
Более того, тот факт что одна и та же модель может быть отображена в другую систему хранения (причем, например, отображение в document-based хранилища приводят к гораздо меньшему количеству «импедансов») говорит о том, что модель на O-конце не особо связана со своим R-концом.
Более того, тот факт что одна и та же модель может быть отображена в другую систему хранения (причем, например, отображение в document-based хранилища приводят к гораздо меньшему количеству «импедансов») говорит о том, что модель на O-конце не особо связана со своим R-концом.
I am too old for this shit
Использую mysql, mongodb, redis, sqlite в разных проектах. Вопрос: что мне нужно выкинуть и срочно начать переписывать работающие приложения? Или может быть не имеет смысла абстрактно обсуждать что лучше/хуже…
Отвечая на Ваш вопрос: Вам необходимо выкинуть sqlite и начать использовать более быструю levelDB которая спроектирована Гуглом как замена дальнейшего развития, исчерпавшего свои возможности, sqlite3
Эээ, зачем? Вы уверены, что у автора предыдущего комментария проблема в скорости? Как вообще LevelDB относится к sqlite? Это 2 совершенно разные базы, одна реляционная с поддержкой sql, другая key-value хранилище, которая вроде как вообще не поддерживает никакого языка запросов. В общем как-то толсто, особенно не зная реальных условий проекта.
А вот болт SQL раз Гугл решил с sqlite3 перейти на k-v LevelDB!
Я Эльф, опровергни!
Факт неоспорим, SQLite дальнейшего развития не получит.
Почему — на это есть веские причины по задачам.
Попробую угадать — SQLite как и все встраиваемые реляционные БД, например mnesia не рассчитаны на хранение большого объема информации потому что начинают тупить. Таким образом если мы сохраним пару томиков «Война и Мир» в SQLite он будет работать с другими запросами как черепашка, а этого не хочется. Таким образом любая встраиваемая БД должна обеспечить быстрый поиск, а быстрым он может быть только по n(1) хеш-таблицам, таким как Google bigTables.
Именно эта технология легла в основу levelDB. При встраивании мы не получаем просадок на объем информации и локи присутствующие в SQLite! разумеется подробности можно посмотреть тут symas.com/mdb/microbench/benchmark.html
Я Эльф, опровергни!
Факт неоспорим, SQLite дальнейшего развития не получит.
Почему — на это есть веские причины по задачам.
Попробую угадать — SQLite как и все встраиваемые реляционные БД, например mnesia не рассчитаны на хранение большого объема информации потому что начинают тупить. Таким образом если мы сохраним пару томиков «Война и Мир» в SQLite он будет работать с другими запросами как черепашка, а этого не хочется. Таким образом любая встраиваемая БД должна обеспечить быстрый поиск, а быстрым он может быть только по n(1) хеш-таблицам, таким как Google bigTables.
Именно эта технология легла в основу levelDB. При встраивании мы не получаем просадок на объем информации и локи присутствующие в SQLite! разумеется подробности можно посмотреть тут symas.com/mdb/microbench/benchmark.html
1. С чего куда гугл решил перейти с sqlite? Он его использовал? Я только знаю в андроиде используется.
2. Зачем во встраиваемых база данных хранить большие объёмы?
3. Что такое n(1)? Это оценка временной сложности операции?
SQL базы дают большое преимущество, что в них стразу встроен язык запросов. Для многих приложений (например в том же андроиде) объём данных не такой большой, чтобы проблема упиралась в производительность базы, а наличие мощного языка запросов упрощает разработку, не надо изобретать самому велосипед. В общем мне кажется sqlite для определенного круга задач весьма хорошо подходит и нет смысла в них пытаться использовать levelDB.
2. Зачем во встраиваемых база данных хранить большие объёмы?
3. Что такое n(1)? Это оценка временной сложности операции?
SQL базы дают большое преимущество, что в них стразу встроен язык запросов. Для многих приложений (например в том же андроиде) объём данных не такой большой, чтобы проблема упиралась в производительность базы, а наличие мощного языка запросов упрощает разработку, не надо изобретать самому велосипед. В общем мне кажется sqlite для определенного круга задач весьма хорошо подходит и нет смысла в них пытаться использовать levelDB.
Зачем во встраиваемых база данных хранить большие объёмы?
Сейчас во встраиваемых объемов побольше чем в корпоративных лет 10 назад :)
SQL базы дают большое преимущество, что в них стразу встроен язык запросов.
Что дает оверхид на его парсинг как минимум. Плюс требуется хороший планировщик из-за неоднозначности порядка выполнения, ну или костыли в языке для его явного задания.
Ничего не выкидывайте, просто циклически замените mysql->mongodb, mongodb ->redis, redis->sqlite, sqlite->mysql. О результатах напишите статью на Хабр.
По стилистике напомнило видео «Хочу четвертый айфон»
Кстати, TokuMX использует lock per document и Fractal tree indexes вместо B-trees
Было бы здорово, если бы в реляционных БД был интерфейс для программ.
А то как-то странно получается, сначала сделали интерфейс для человека (язык запросов, SQL), а теперь всякими ORM/querybuilder-ами подбиваются костыли
А то как-то странно получается, сначала сделали интерфейс для человека (язык запросов, SQL), а теперь всякими ORM/querybuilder-ами подбиваются костыли
что-то в этом есть. вполне можно было бы не «переписывая всё с нуля» сделать это — например, написать php-extension, который работает как простой ORM или хотя бы как Model в CakePHP с find (там conditions мне нравятся), save, updateAll, delete, deleteAll.
Особого профита, думаю, не получится по сравнению со обычными ОРМ — так же отправлять SQL запросі текстом и так же парсить текстовый ответ.
всё-таки есть небольшой overhead :)
источник: vincent-lecomte.blogspot.com/2011/01/web-php-zend-benchmark-pdo-vs-doctrine.html
источник: vincent-lecomte.blogspot.com/2011/01/web-php-zend-benchmark-pdo-vs-doctrine.html
Не думаю, что будет значительная разница если маппить сишным расширением. Быть-то то она будет, но сомнительно что будет большой профит. Хотя, если удастся преодолеть затык на рефлексии, то может и взлететь.
Можно без объектов — массивами, без указания списка полей. Так работает CakePHP.
Это менее идеологически верно, но зато можно писать очень мало кода.
Смысл в том, чтобы можно было писать:
а вернулся массив
Это менее идеологически верно, но зато можно писать очень мало кода.
Смысл в том, чтобы можно было писать:
$AlmostNoSql->model('Customer')->find('all', [
'fields' => ['id', 'name', 'MAX(Invoice.paid_date) as last_paid_date'],
'contain' => ['Invoice' => ['paid_date', 'amount']],
'conditions' => [
'Invoice.paid_date NOT' => null,
'Customer.account_expire_date <=' => date('Y-m-d'),
],
'order' => 'Customer.last_login_date DESC'
]);а вернулся массив
[
[
'Customer' => ['id' => 1, 'name' => 'Jack', 'last_paid_date' => '2013-11-01'],
'Invoice' => [
['paid_date' => '2013-11-01', 'amount' => 200],
['paid_date' => '2013-10-01', 'amount' => 200]
]
],
[
'Customer' => ['id' => 2, 'name' => 'Jill', 'last_paid_date' => '2013-11-05'],
'Invoice' => [
['paid_date' => '2013-11-05', 'amount' => 100]
]
]
]
> Если devnull горизонтально масштабируется, я буду использовать его. Devnull горизонтально масштабируется?
Хорошо, когда твои конкуренты так «разбираются» в технологии.
Плохо, когда в родной компании возникает такой «апологет новой эры» :)
Хорошо, когда твои конкуренты так «разбираются» в технологии.
Плохо, когда в родной компании возникает такой «апологет новой эры» :)
Если devnull горизонтально масштабируется, я буду использовать его. Devnull горизонтально масштабируется?
Вот эти парни доказали, что масштабируется.
Извините, но мой внутренний граммар-наци, говорит что «Вы откладываете запись данных позже.» лучше заменить на «Вы откладываете запись данных „на потом“. » Поменяйте, а то глаза режет. :-)
А я использую PostgresSQL…
Посоны, может вы мне поможете. Пытаюсь установить MongoBD, пишет старбакс драйвер не установлен. Что делать?
здесь подскажут toster.ru/tag/mongodb
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MongoDB Is Web Scale