How to become an author
Search
Write a publication
Pull to refresh

Comments 46

спасибо, переименовал статью, а то была неузнаваемой.
люди думали, что это всерьёз и минусовали.
This comment wasn’t rated yet0
просто предположение: может быть люди минусуют потому что смехуечка попала в три тематических хаба вместо Чулана, где ей место?
Total votes 8: ↑4 and ↓40
«Сказка – ложь, да в ней намёк, добрым молодцам урок»
Total votes 8: ↑4 and ↓40
если бы не увидел тег Внимание: тег «юмор»., то минуснул бы…
а так спасибо за юмор, с утра подняло настроение.
Total votes 4: ↑1 and ↓3-2
Этот диалог необходимо смотреть в оригинальном исполнении, чтобы не потерять всех эмоций, которые передают актёры.
mongodb-is-web-scale.com/
Total votes 7: ↑7 and ↓0+7
Я имел в виду оригинальное исполнение, а не оригинальный первоисточник.
Total votes 1: ↑1 and ↓0+1
С сожалением, пришлось отказаться от Монго, так как он съедал память на моём единственном сервере. А выделенный сервер, это пока слишком жирно. Может есть способы его вернуть?
This comment wasn’t rated yet0
если жалко выделенный сервер, то, наверное, решаемая задача не «web scale» и достаточно MySQL :)
Total votes 4: ↑4 and ↓0+4
Браво, просто таки ошеломляющая победа над «чучелом Mongo».

Очень не люблю фанатиков, и ОСОБЕННО ненавижу фанатиков древних как окаменевшее говно мамонта технологий. Нет, я уже недостаточно молод для "… до основанья, а затем..." и вполне признаю право устаревших технологий на продолжение своего существования, но фанатеть от них?

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

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

В SQL мы имеем глобальные процедуры и функции (триггеры и отображения являются специализированными процедурами), из типов данных — пучок примитивных типов данных (нет беззнаковых целых, но есть двоично-десятичные дроби — кто вообще до сих пор считает это хорошей идеей?) плюс таблицы. Все. Это настолько примитивно, что даже некоторые ассемблеры более выразительны.
Total votes 27: ↑10 and ↓17-7
ну, во-первых, напомню о теге «юмор» :)

я активно использую 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.
не стоит хвататься за всё модное, если нет желания вникать как оно работает, а просто чувствовать себя в тренде.
Total votes 5: ↑5 and ↓0+5
я активно использую MySQL лет 9, но SQL-запросы в коде не писал уже несколько лет

А как вы делаете запросы данных на стороне сервера? Как можно написать скрипт заменяющий MySQL запрос?
Total votes 6: ↑1 and ↓5-4
JPA или что нибудь подобное?
This comment wasn’t rated yet0
Ну дык это и не Ваше творение — оригинальный автор похоже не шутил (вернее, скорее всего он считал, что насмехается над «фанатами» Mongo).

Да мепперы спасают до определенной степени (я по возможности пытаюсь выносить запросы в LINQ, оставляя саму базу практически без хранимых процедур), но они лишь явственно очерчивают проблему с SQL, а не решают ее (ну и приносят импеданс, про который упомянул автор, а вернее пару десятков оных). То есть по сути ORM-ы — тоже NoSQL.

От RDBMS остается фактически только хранение B-деревьев, с чем вполне справляются всякие BDB, да и все остальные БД — как SQL так и NoSQL (включая Mongo) используют B-деревья как основную структуру данных для хранения индексов.

Что же до Mongo — да, глобальный лок — ОЧЕНЬ спорное решение изначально, с другой стороны она таки действительно масштабируется горизонтально (и, как Вы отметили, этот самый лок разбивается на несколько — в каждом mongod свой). Ну и отлично понимая, что я — «нерепрезентативная выборка», но в моем личном опыте неосторожное обращение с констрейнтами убило больше производительности, чем глобальный лок в Mongo.
Total votes 7: ↑4 and ↓3+1
> То есть по сути ORM-ы — тоже NoSQL.

С какой это стати? Типичная ORM-выборка по связанным объектам транслируется в пачку джойнов. Да что там, в том же LINQ джойны даже явно фигурируют. И транзакции и прочее тоже вполне SQL-подобны.
Total votes 2: ↑1 and ↓10
Ну, прежде всего, в ORM-ах нет реляционной алгебры (по крайней мере на объектном конце — именно поэтому нужен «меппинг»).

Если же говорить конкретно про LINQ, то join-ы в нем семантически больше похожи на таковые в XQuery: декартово произведение сущностей с фильтрацией зависимых (вместо генерации нового множества кортежей со значениями). То что некоторые LINQ провайдеры генерируют на выходе SQL — отнюдь не означает, что LINQ это и есть SQL (просто с другим синтаксисом) — между ними семантическая (а не синтаксическая — как раз синтаксис относительно близок) пропасть.
То есть образно говоря, LINQ настолько же не SQL, насколько, например, C++ — это не машинный код.
Total votes 1: ↑1 and ↓0+1
ORM — NoSQL формально, но всё равно RDBMS.
Total votes 1: ↑1 and ↓0+1
Нет, реляционной алгеброй в ORM-ах не пахнет. Все операторы реляционной алгебры отображают кортежи в кортежи. Любая агрегация (в смысле включения одних объектов и коллекций в другие, а не свертка набора значений в одно) — это уже очень существенно нереляционно (собственно говоря, это один из тех самых «impedance mismatch»-ей: O-часть ORM-а работает над графом зависимостей, а R-часть — над множествами кортежей).

Более того, тот факт что одна и та же модель может быть отображена в другую систему хранения (причем, например, отображение в document-based хранилища приводят к гораздо меньшему количеству «импедансов») говорит о том, что модель на O-конце не особо связана со своим R-концом.
Total votes 1: ↑1 and ↓0+1
I am too old for this shit
This comment wasn’t rated yet0
Использую mysql, mongodb, redis, sqlite в разных проектах. Вопрос: что мне нужно выкинуть и срочно начать переписывать работающие приложения? Или может быть не имеет смысла абстрактно обсуждать что лучше/хуже…
Total votes 1: ↑1 and ↓0+1
Отвечая на Ваш вопрос: Вам необходимо выкинуть sqlite и начать использовать более быструю levelDB которая спроектирована Гуглом как замена дальнейшего развития, исчерпавшего свои возможности, sqlite3
Total votes 10: ↑3 and ↓7-4
Эээ, зачем? Вы уверены, что у автора предыдущего комментария проблема в скорости? Как вообще LevelDB относится к sqlite? Это 2 совершенно разные базы, одна реляционная с поддержкой sql, другая key-value хранилище, которая вроде как вообще не поддерживает никакого языка запросов. В общем как-то толсто, особенно не зная реальных условий проекта.
Total votes 2: ↑2 and ↓0+2
А вот болт SQL раз Гугл решил с sqlite3 перейти на k-v LevelDB!
Я Эльф, опровергни!
Факт неоспорим, SQLite дальнейшего развития не получит.
Почему — на это есть веские причины по задачам.

Попробую угадать — SQLite как и все встраиваемые реляционные БД, например mnesia не рассчитаны на хранение большого объема информации потому что начинают тупить. Таким образом если мы сохраним пару томиков «Война и Мир» в SQLite он будет работать с другими запросами как черепашка, а этого не хочется. Таким образом любая встраиваемая БД должна обеспечить быстрый поиск, а быстрым он может быть только по n(1) хеш-таблицам, таким как Google bigTables.
Именно эта технология легла в основу levelDB. При встраивании мы не получаем просадок на объем информации и локи присутствующие в SQLite! разумеется подробности можно посмотреть тут symas.com/mdb/microbench/benchmark.html
Total votes 1: ↑0 and ↓1-1
1. С чего куда гугл решил перейти с sqlite? Он его использовал? Я только знаю в андроиде используется.
2. Зачем во встраиваемых база данных хранить большие объёмы?
3. Что такое n(1)? Это оценка временной сложности операции?

SQL базы дают большое преимущество, что в них стразу встроен язык запросов. Для многих приложений (например в том же андроиде) объём данных не такой большой, чтобы проблема упиралась в производительность базы, а наличие мощного языка запросов упрощает разработку, не надо изобретать самому велосипед. В общем мне кажется sqlite для определенного круга задач весьма хорошо подходит и нет смысла в них пытаться использовать levelDB.
Total votes 2: ↑1 and ↓10
Зачем во встраиваемых база данных хранить большие объёмы?

Сейчас во встраиваемых объемов побольше чем в корпоративных лет 10 назад :)
SQL базы дают большое преимущество, что в них стразу встроен язык запросов.

Что дает оверхид на его парсинг как минимум. Плюс требуется хороший планировщик из-за неоднозначности порядка выполнения, ну или костыли в языке для его явного задания.
Total votes 2: ↑1 and ↓10
Ничего не выкидывайте, просто циклически замените mysql->mongodb, mongodb ->redis, redis->sqlite, sqlite->mysql. О результатах напишите статью на Хабр.
Total votes 9: ↑9 and ↓0+9
По стилистике напомнило видео «Хочу четвертый айфон»
Total votes 1: ↑1 and ↓0+1
Люди немного побаиваются нестандартных решений и боятся прекращения поддержки, поэтому остаются на оригинальной Mongo и учатся жить с её особенностями.
Total votes 1: ↑1 and ↓0+1
Было бы здорово, если бы в реляционных БД был интерфейс для программ.
А то как-то странно получается, сначала сделали интерфейс для человека (язык запросов, SQL), а теперь всякими ORM/querybuilder-ами подбиваются костыли
Total votes 11: ↑11 and ↓0+11
что-то в этом есть. вполне можно было бы не «переписывая всё с нуля» сделать это — например, написать php-extension, который работает как простой ORM или хотя бы как Model в CakePHP с find (там conditions мне нравятся), save, updateAll, delete, deleteAll.
This comment wasn’t rated yet0
Особого профита, думаю, не получится по сравнению со обычными ОРМ — так же отправлять SQL запросі текстом и так же парсить текстовый ответ.
This comment wasn’t rated yet0
Не думаю, что будет значительная разница если маппить сишным расширением. Быть-то то она будет, но сомнительно что будет большой профит. Хотя, если удастся преодолеть затык на рефлексии, то может и взлететь.
This comment wasn’t rated yet0
Можно без объектов — массивами, без указания списка полей. Так работает 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]
        ]
    ]
]
This comment wasn’t rated yet0
> Если devnull горизонтально масштабируется, я буду использовать его. Devnull горизонтально масштабируется?

Хорошо, когда твои конкуренты так «разбираются» в технологии.

Плохо, когда в родной компании возникает такой «апологет новой эры» :)
Total votes 10: ↑10 and ↓0+10
Если devnull горизонтально масштабируется, я буду использовать его. Devnull горизонтально масштабируется?

Вот эти парни доказали, что масштабируется.
This comment wasn’t rated yet0
Извините, но мой внутренний граммар-наци, говорит что «Вы откладываете запись данных позже.» лучше заменить на «Вы откладываете запись данных „на потом“. » Поменяйте, а то глаза режет. :-)
Total votes 1: ↑0 and ↓1-1
поменял, спасибо.
но, вообще, по этикету хабра — такое лучше в личку, чтобы не отвлекать людей от чтения комментариев по существу ;)
Total votes 5: ↑5 and ↓0+5
Ок. Приму к сведению.
This comment wasn’t rated yet0
Посоны, может вы мне поможете. Пытаюсь установить MongoBD, пишет старбакс драйвер не установлен. Что делать?
Total votes 3: ↑1 and ↓2-1
Sign up to leave a comment.

Articles

Show the best of all time
Unlock dark mode

Your account

Sections

Information

Services

Support
© 2006–2024, Habr