Майкл Стоунбрейкер (Michael Stonebraker (http://ru.wikipedia.org/wiki/%D0%A1%D1%8... один из основоположников теории баз данных, принимавший участие в разработке архитектуры СУБД как Ingres, Informix, PostgreSQL, SciDB (http://www.opennet.me/opennews/art.shtml?num=30983) и VoltDB (http://www.opennet.me/opennews/art.shtml?num=26732), рассуждая (http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse... о масштабировании СУБД, упомянул, что поддержание огромной и сложной реализацией MySQL в Facebook "хуже чем смерть" и есть только один выход из сложившейся проблемы - сделать невозможное и переписать весь код. Это проблема касается и многих других web компаний, которые начинают с малого, а затем увеличиваются до огромных размеров.
В настоящее время, чтобы справится с нагрузкой, которую создают 750 миллионов пользователей, Facebook оперирует четырьмя тысячами экземпляров (исполь...URL: http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse.../
Новость: http://www.opennet.me/opennews/art.shtml?num=31142
И кто им мешал PostgreSQL использовать??
отсутствие нормального орма видимо
орм не нужен, особенно в таких нагруженных проектах.
> И кто им мешал PostgreSQL использовать??Postgre еще более ущербен на primaryKey-value. Его вселенная - приложения.
Да ну неужели ?
А вы представляете что это значит? Такие гиганты говорят что настоящая БД не годится. Это как раньше пользовались при шифровании ключом в 56 бит и считалось что это достаточно, но на перед видилось что будут новые машины и что и 256 бит скоро будет не хватать. Просто наперед начать переписывать с нуля то что есть сейчас...это офигенный прогресс!!!!MS со своим 2008 SQL только бы хотелось узнать как,потянут базы от таких гигантов или нет? Думают ли они о будущем и то что ЭТОГО уже мало?
Сперва они упираются в тормознутость PHP и решают написать компилятор из PHP в C. Потом они упираются в MySQL и решают написать свою БД. Что дальше? Небольшой [свечной] микропроцессорный заводик? Собственная сеть спутников?
А почему бы и нет. Например аппаратное ускорение работы базы.
Тогда любой запрос можно превратить в один ioctl(SQL_REG, IO_SELECT, *data_pointer);
с другой стороны ускорителя :) втыкать всяки носители, хоть USB-плешку.
Две USB дыкри и кнопка [ FAST BACKUP ] - аналог dd if USB1 of USB2
Это было бы занимательно. Только, учитывая опыт компилятора, не для простых смертных это, будет требовать гелиевого охлаждения и отдельного энергоподвода от ближайшей электростанции.
ну а что тут такого? Любой проект, если он растет, сталкивается с проблемами (не только масштабирования, но и бизнес, и сетью, и управлением, и разработкой). Их путь повторяет опыт Гугла: слабые ФС - делаем свою, слабые серверы - делаем (заказываем) свои и т.д.я наблюдал несколько небольших компаний, которые с самого начала пытались делать сверхоптимизированные проекты - проели кучу денег, на запуск и раскрутку тупо не хватило.
Согласен полностью. Если им не хватает чего то пусть пишут. Нам главное учесть их опыт и пропускать мимо ушей все эти "нанотехнологии". А то уже гугль пол инета готов закопать, эти вот sql готовы закопать ...
Интересно, они думают, что если SQL записывать в нижнем регистре, это избавит от проблем масштабируемости?
интересно, ты думаешь что написав пару язвительных комментариев о том, чего не понимаешь, ты сможешь казаться специалистом в данном вопросе?
ты уже научился "по фотографии" определять кто специалист и кто нет?
Нет. А вы так думаете?
>> написав пару язвительных комментариев о том, чего не понимаешь,
>> ты сможешь казаться специалистом в данном вопросе?а вдруг наоборот?
>> Интересно, они думают, что если SQL записывать в нижнем регистре,
>> это избавит от проблем масштабируемости?Усовершенствования это круто, но ОТХОДИТЬ ОТ СТАНДАРТОВ SQL-синтаксиса -- нехорошо в кубе.
Граждане не просто регистром балуются, а мостырят какую-то "феню".
Это их сайт, их язык, их программисты и их сообщество, нифиг им совместимость? ИМХО, главное, чтобы работало
"Их сайт", то есть Фейсбук, как раз нуждается в совместимости, ибо на MySQL.
А Stonebraker просто рядом стоит.
Соблазняя Фейсбуков отойти от ANSI синтаксиса.
ну так многие уже отошли от стандарта, NoSQL используют
Ткните пальцем. Во многих.И:
Вас ист дас "nosql"? "Key-value"?
Какое отношение "k-v" имеет к обсуждаемому тут NewSQL?
>Усовершенствования это круто, но ОТХОДИТЬ ОТ СТАНДАРТОВ SQL-синтаксиса -- нехорошо в кубе.тем более не понятно, как изменение синтаксиса решит вопрос масштабирования и производительности.
Зыж
ну давайте все говорить по-английски.
Глядишь и ввп удвоится.
Этот человек производит впечатление психа.
На сайте, кстати, ничего, кроме рассуждений о том, что "синтаксис SQL громоздок".
И цель проекта заявлена, собственно, как новый синтаксис и только новый синтаксис.
О движке и его производительности ни звука.
Насколько я знаю SQL в mysql регистронезависим. Так что проблему производительности можно решить решить простой заменой. <сарказм>
Именно! ;)
А что, кому-то от этого плохо? Думаю сообщество только от этого выиграет, они же не будут исходники зажимать? Так и появляются хорошие открытые проекты, которые разрабатываются за деньги больших богатых контор.
Это не плохо. Это просто выглядит несколько… забавно. Весёлая компания.
> А что, кому-то от этого плохо? Думаю сообщество только от этого выиграет,
> они же не будут исходники зажимать? Так и появляются хорошие открытые
> проекты, которые разрабатываются за деньги больших богатых контор.КТО и ЧТО "выиграет" от синтаксиса НАД SQL???
Вы на сайт NewSQL заходили?
Смахивает на рекламу NewSQL.Вообще, FB отлично на MySQL работает, и, кажется, всё это профанация для личной выгоды.
> Смахивает на рекламу NewSQL.чем и является, собственно. «мы наш, мы новый мир построим! дайте бабла уже!»
Гугль давно свой велосипед изобрел для таких целей. Фэйсбук тоже доэволюционировал до этого, видимо
У гугла немного другой круг задач, т.е. цели там другие. А так есть похожие открытые велосипеды как у гугла - apache hadoop. Ява, но конторы с аналогичными целями его успешно используют.
не понял, за счет чего повышается производительность?
Кто сказал что она повышается? Кроме кучи текста пока ещё ничего нет.
В статье представлены 6 компаний, у которых есть масштабируемые СУБД.
> В статье представлены 6 компаний, у которых есть масштабируемые СУБД.-- ни одна из которых проблем, которые "6 компаний" берутся порешать, -- не решила.
> не понял, за счет чего повышается производительность?за счет разнесения на разные сервера и развязывания обработки. поскольку нет требования консистентности, то не требуется координатор транзакций - а он бутылочное горлышко любой распределенной БД. Раз убрали боттел-нек, то и скорость серьезно повышается. Минус - переход от консистентности к "Eventual consistency"
Eventual consistency - это что при прекращении нагрузки система самостоятельно раскатит все транзакции по всем серверам и вся БД придет в согласованное состояние. Но поскольку нагрузка никогда не будет уменьшена, то и согласованность БД не будет достигнута ;)
Когда до людей дойдёт, что централизованные сервисы ненужны?Всем известный пример - есть ICQ, которая стабильно падает и глючит, и есть джаббер, который работает. И есть распределённый email, который спокон веков работал на любом копеечном железе и как-то обходился без ВЫСОКИХ НАГРУЗОК, МАСШТАБИРОВАНИЯ и NOSQL. И для социальных сетей давно есть распределённая Diaspora, в которой каждый сам хозяин своих даных - но нет, мыши плакали, кололись, но упорно несли свои личные фконтактик и ффейсбук. А создатели вктонактика и фейсбука мужественно борются с проблемами масштабирования, которые сами же себе и придумали. Воистину, все беды от дурости.
> давно есть распределённая DiasporaОфициально ещё не вышла, но да - есть серверы со свободной регистрацией.
Что значит "не вышла"? git clone git://github.com/diaspora/diaspora.git
THIS IS ALPHA SOFTWARE AND SHOULD BE TREATED ACCORDINGLY. IT IS FUN TO GET RUNNING, BUT EXPECT THINGS TO BE BROKEN.
Вконтактик всю жизнь ALPHA SOFTWARE, и разве кого-то это останавлиет?
> Официально ещё не вышла, но да - есть серверы со свободной регистрацией.Гугол+ тоже ещё официально не вышел, а все уже бегут в очередь становиться, лол.
> Когда до людей дойдёт, что централизованные сервисы ненужны?Тогда, когда некоторая [коммерческая] компания проведёт, по сути, рекламную акцию среди _некомпьютерного_ населения по внедрению распределённой социальной сети. Для этого должны быть созданы и отшлифованы пригодные для _некомпьютерного_ населения клиенты и _сервера_ , налажено взаимодействие с аналогичными службами (гейты в твиттер, фейсбук и blogger.com - популярная тема) и так далее и тому подобное.
А на выходе, напомню, - _распределённая_ социальная сеть. С такой сети и персональные данные фиг поколлекционируешь :) В общем, не слишком очевиден способ монетизации, ведь вводить абонентку или перегрузить рекламой - это подписать себе смертный приговор ещё на взлёте. Вот и не занимается этим никто всерьёз.
А "мыши" и прочие "хомячки", с одной стороны, не воспринимают свои персональные данные как нечто коммерчески ценное и приватное, а с другой - чаще всего не задумываются над тем, что хозяин ресурса обладает полным доступом к тому, что они показали хоть кому-то.
>монетизацииПричём тут монеты?
>>монетизации
> Причём тут монеты?Для поднятия ЧСВ себе и оплаты еды программистам, пишущим код.
Нумизмат?
> Когда до людей дойдёт, что централизованные сервисы ненужны?Фейсбук приносит деньги акционерам фейсбука?
Значит, фейсбук нужен.
Как минимум, нужен этим самым акционерам.Вложить бабло в разработку красивого сайта, прорекламировать, нагнать пользователей, поднять посещаемость, ввести платные услуги, получить ещё больше бабла на выходе.
Вот и вся любовь.
> есть только один выход из сложившейся проблемы - сделать невозможное и переписать весь код. Эта проблема касается и многих других web-компанийВообще почему ограничились только Web-компаниями мне например не нравиться что ядро подтормаживает когда make QT в сто потоков ставишь ;)
> make QTу тебя есть исходники QuickTime? поделись!
Млин, кругом тролли... Ты вот зачем опять троллишь тут красноглазая?Ссылка на исходники qt:
> Млин, кругом тролли… Ты вот зачем опять троллишь тут красноглазая?
> Ссылка на исходники qt:
> http://qt.nokia.com/downloadsа что такое «qt»? QT — это QuickTime. Qt — это тулкит от нокии. а «qt» — это что такое?
>> make QT
> у тебя есть исходники QuickTime? поделись!^)))))))))))))))) блин. я долго так не плакал на работе...
Выкинь systemd и включи автогруп шедулинг.
> который имеет значительно более высокую производительность, чем обычные SQL DB,
> при этом гарантирует выполнение требований ACID. NewSQL пока находится на
> стадии проектирования, ещё даже не принят язык запросов - решается вопрос о
> выборе между синтаксисом похожим на Java и синтаксисом, напоминающим
> обычные SQL-запросы.Отлично... Еще не начали делать, а уже говорят что будет быстрее. Запросы лучше писать в виде функций и запросов примитивных. То есть в идеале уход от SQL и приход к чуть ли не ручному foreach. Только тогда программисты смогут сами понимать на сколько сложно искать что-то... И не потребуеться много времени на разор SQL.
> Только тогда программисты смогут сами понимать на сколько сложно искать что-то...ты не поверишь: компьютеры были придуманы как раз для того, чтобы поменьше тупой ручной работы делать. сюрпрайз?
>То есть в идеале уход от SQL и приход к чуть ли не ручному foreach. Только тогда программисты смогут сами понимать на сколько сложно искать что-то... И не потребуеться много времени на разор SQL.Большинство программистов не сможет написать "форичами" план выполнения быстрее чем это делают оптимизаторы запросов в нормальных СУБД. А php быдлокодеры были, есть и будут независимот ни от чего делать на каждый чих по 1000 запросов к БД.
> И не потребуеться много времени на разор SQL.
на разбор SQL выражений времени и так много не требуется.
> А php быдлокодеры были, есть и будут независимот ни от чего делать на каждый чих по 1000 запросов к БДSELECT current_date;
:-)))))))))))))))
Похоже, что проекту, указанному в новости, не хватает одного, но грамотного руководителя проекта.При грамотном руководителе проекта мы бы знали, что проект работает, а не видели периодические отмазки, выполнзающие наружу.
IMHO, естественно.
1) sql - гавно, перепишем
2) реляционный БД - гавно - перепишемНу да - такой подход veni, vidi, vici крут. Чего там - стандарт SQL придумали трусы. Почитать известнейших теоретиков БД тоже не судьба - читать тоже придумали трусы. Объектные БД уже были (и еще есть - ниша специфичная) и как-то популярности не набрали.
"NewSQL пока находится на стадии проектирования", но уже "имеет значительно более высокую производительность, чем обычные SQL DB"у них бенчмарк через libastral работает?
Еще круче - у них машина времени
А про то, что при разработке вначале пишут прототип на чём-то лёгком из ООП-языков, вы слышали? Если прототип показывает увеличение производительности, то релиз данной БД будет намного производительней прототипа.
Не смешите, с такими ёмкими проектами так не бывает. И лёгкий язык даст слишком большую просадку по скорости какая бы там продвинутая архитектура не была. И существенно продвинутую архитектуру придумать практически невозможно, из статьи же что говорит сам автор о NoSQL:"Кроме этого, по мнению Стоунбрейкера NoSQL обладает не сильно возросшей производительностью относительно традиционных SQL-ориентированных СУБД"
Т.е. ноэскюэльщики с наскока существенно решить ничего не смогли. И прототипы всегда имеют более облегчённый функционал, который потом становится ещё сложнее.
Подобные проекты пишутся только "на удачу", т.е. с надеждой что выбранная архитектура и дальнейшая многогодовая разработка действительно даст хороший результат. Не может у него быть такого прототипа сейчас.
Правильно мыслит товарищ, надеюсь что синтаксис запросов выберут единственно верный: NewSQL, вариант 'Jdb'. Очень правильный синтаксис. А мерзкий недоязычок SQL надо закопать.
до... превратить:
WHERE T.ID=T2.ID
в:
t1.join(t2[t1.id==t2.id])
это круто, это правильно, это мега правильно. представляю как будет выглядеть что-нить типа:SELECT p.*, pa.`id_product_attribute`, pl.`description`, pl.`description_short`, pl.`available_now`, pl.`available_later`, pl.`link_rewrite`, pl.`meta_description`, pl.`meta_keywords`, pl.`meta_title`, pl.`name`, i.`id_image`, il.`legend`, m.`name` AS manufacturer_name, tl.`name` AS tax_name, t.`rate`, cl.`name` AS category_default, DATEDIFF(p.`date_add`, DATE_SUB(NOW(), INTERVAL 0 DAY)) > 0 AS new, (p.`price` * ((100 + (t.`rate`))/100) - IF((DATEDIFF(`reduction_from`, CURDATE()) <= 0 AND DATEDIFF(`reduction_to`, CURDATE()) >=0) OR `reduction_from` = `reduction_to`, IF(`reduction_price` > 0, `reduction_price`, (p.`price` * ((100 + (t.`rate`))/100) * `reduction_percent` / 100)),0)) AS orderprice
FROM `ps_category_product` cp
LEFT JOIN `ps_product` p ON p.`id_product` = cp.`id_product`
LEFT JOIN `ps_product_attribute` pa ON (p.`id_product` = pa.`id_product` AND default_on = 1)
LEFT JOIN `ps_category_lang` cl ON (p.`id_category_default` = cl.`id_category` AND cl.`id_lang` = 4)
LEFT JOIN `ps_product_lang` pl ON (p.`id_product` = pl.`id_product` AND pl.`id_lang` = 4)
LEFT JOIN `ps_image` i ON (i.`id_product` = p.`id_product` AND i.`cover` = 1)
LEFT JOIN `ps_image_lang` il ON (i.`id_image` = il.`id_image` AND il.`id_lang` = 4)
LEFT JOIN `ps_tax` t ON t.`id_tax` = p.`id_tax`
LEFT JOIN `ps_tax_lang` tl ON (t.`id_tax` = tl.`id_tax` AND tl.`id_lang` = 4)
LEFT JOIN `ps_manufacturer` m ON m.`id_manufacturer` = p.`id_manufacturer`
WHERE cp.`id_category` = 63 AND p.`active` = 1
ORDER BY `quantity` DESC
LIMIT 76610,10это-то фиг поймешь и осмыслишь, а с ждб вообще себе пулю в лоб можно сразу пускать.
Или такое http://juick.com/zoonman/1343226
Такие портянки в приличных местах не показывают.
Одни только магические константы чего стоят.
> Такие портянки в приличных местах не показывают.
> Одни только магические константы чего стоят.вы с этим к 1с сходите.
> вы с этим к 1с сходите.В 1с код пишется на языке 1с, а не на голом SQL-е, так что мимо кассы.
Баян, работающая версия которого называется LINQ(2db). Проблема выразительности языка, что в его работающем решении, что в примерах не решена.
Любишь кататься, люби и саночки возить
наконец они решили делать Google Big Table
> наконец они решили делать Google Big TableОткуда этот забавный вывод?
Почему не запилят соцсеть по принципу i2p?
Диаспора по принципу джаббера - этого достаточно.
На мой взгляд, бесполезное занятие себе господа выдумали. Да, у SQL есть проблемы. Много случаев, когда приходится заниматься копированием подзапросов или плодить пачки VIEW. Полный бардак с хинтами. Беда с объединением множеств (UNION тормоз, а FULL JOIN повесишься фильтровать). А здесь предлагается просто изменением синтаксиса SQL решать проблемы производительности. Не поддерживаю...
UNION ALL еще не изобрели?
> UNION ALL еще не изобрели?Я же сказал - тормоз. Пусть есть у меня достаточно сложный запрос по двум десяткам таблиц с вложенными SELECT. Пусть мне надо выбрать из него два пересекающихся подмножества с разными GROUP BY. В итоге мне приходится или оформлять этот запрос как VIEW и объединять два запроса через UNION, либо просто копировать этот запрос для второй части. В любом случае, ни Postgres, ни MSSQL, ни Oracle, ни MySQL не понимают, что можно сделать одну выборку, а не две.
Неправда. В Pg, Оракл и некоторых других СУБД есть оконные функции, часть подобных задач с их помощью решать можно.
> Неправда. В Pg, Оракл и некоторых других СУБД есть оконные функции, часть
> подобных задач с их помощью решать можно.Вот и подтверждение моему утверждению. Проблема известна, некоторые разработчики БД придумывают расширения для SQL, пытаясь решить проблему. Хотя более правильным, была бы разработка либо нового стандарта SQL(что хуже), либо нового языка запросов к БД.
> В любом случае, ни Postgres, ни MSSQL, ни Oracle, ни MySQL
> не понимают, что можно сделать одну выборку, а не две.
>> В любом случае, ни Postgres, ни MSSQL, ни Oracle, ни MySQL
>> не понимают, что можно сделать одну выборку, а не две.
> http://www.postgresql.org/docs/9.0/static/queries-with.htmlЗнаю. Но при построении отчета дополнительные условия WHERE я могу наложить только на последний SELECT. Из-за этого вложенные гребут все не фильтруя - прощай оптимизация.
даёшь JITSql
Переписывать SQL в синтаксисе Джабы (ну или в другом регистре! :) ) - смысла нет, тут нужен принципиально другой подход. Мне вот, извините за кощунство, принцип FoxPro кажется чем-то перспективным. Т.е. мы не просто закинули на сервер монстр-запрос, а на низком уровне говорим серверу, что-откуда взять, как отфильтровать и куда приджойнить. Каков бы ни был оптимизатор, человек лучше знает СЕМАНТИКУ данных, т.е. его запросы будут априори лучше. Да и сам SQL довольно неуклюж для нетривиальных задач - он оперирует множествами, а это не всегда удобно.
Мне тоже нравится подход, когда любой запрос (даже если движок имеет другой фронт) транслируется в SQL, который предоставляется мне для ревизии.
> Каков бы ни был оптимизатор,
> человек лучше знает СЕМАНТИКУ данных, т.е. его запросы будут априори лучше.Увы, это часто совсем не так. Человек не знает, да и не может знать, статистик таблиц БД.
> Да и сам SQL довольно неуклюж для нетривиальных задач - он
> оперирует множествами, а это не всегда удобно.
Автор этой статьи АБСОЛЮТНО не понимает о чем пишет. И ни один(!) комментатор не понял этого.Этот тупица взял отличную статью от GigaOM и приписал туда несуществуюший _проект_ NewSQL. Несуществующий проект затем был привязан к _проекту синтаксиса_ мертвого с 2003го (!) года на sourceforge.
VoltDB кстати работает отлично.
блять, ну почему базы сразу в Jdb было не сделать??