The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

PHP-транслятор HipHop позволил Facebook использовать в разы ..., opennews (ok), 04-Апр-11, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


12. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от Иван Иванович Иванов (?), 04-Апр-11, 15:12 
Заранее скажу, что архитектура вашего сайта крайне неэффективная.

99% (кроме громадин типа facebook/vk/yahoo/etc) сайтов упираются в работу с SQL, но никак не в производительность PHP.

Ответить | Правка | Наверх | Cообщить модератору

13. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +9 +/
Сообщение от бедный буратино (ok), 04-Апр-11, 15:14 
99% (кроме громадин типа facebook/vk/yahoo/etc) сайтов по сути вообще не нужен SQL.

Ответить | Правка | Наверх | Cообщить модератору

135. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –3 +/
Сообщение от User294 (ok), 04-Апр-11, 21:32 
> 99% (кроме громадин типа facebook/vk/yahoo/etc) сайтов по сути вообще не нужен SQL.

А там он начинает тормозить, вызывая батхерт... :P

Ответить | Правка | Наверх | Cообщить модератору

18. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –3 +/
Сообщение от diff (??), 04-Апр-11, 15:28 
> Заранее скажу, что архитектура вашего сайта крайне неэффективная.
> 99% (кроме громадин типа facebook/vk/yahoo/etc) сайтов упираются в работу с SQL, но никак не в производительность PHP.

Да PHP и SQL - "сладкая парочка", друг друга стоят.

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

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

Просто типичный ширпотреб.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

140. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +1 +/
Сообщение от ukko (?), 04-Апр-11, 22:22 
Я посмотрю на то как вы на NoSQL будете реализовывать гибкие выборки, с кучей условий.

NoSQL - это быстро, модно и удобно для хранения плоских списков. А для хранения всего остального в NoSQL мы получаем сплошной геморрой.

Так что реляционные базы ещё будут жить и жить

Ответить | Правка | Наверх | Cообщить модератору

145. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 05-Апр-11, 00:04 
> Я посмотрю на то как вы на NoSQL будете реализовывать гибкие выборки, с кучей условий.
> NoSQL - это быстро, модно и удобно для хранения плоских списков. А для хранения всего остального в NoSQL мы получаем сплошной геморрой.

Только что нагулили?
Нет такой системы - NoSQL. Это собирательное название. Поэтому сделать что-то "в NoSQL" нельзя.

Если вы чем-то не знаете как пользоваться - то конечно у вас получится сплошной геморрой.

> Так что реляционные базы ещё будут жить и жить

Конечно будут. Столько на них наколбасили. И столько народу им обучено.
Только это не проблемы тех, кто от них освободился.

Ответить | Правка | Наверх | Cообщить модератору

147. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 05-Апр-11, 00:19 
Гм, а кроме SQL/NoSQL ничего нет, что ли?

Те же Cache/GTM -- они вовсе не key-value, а иерархические внутри.  И многие вещи из реального мира действительно лучше укладываются в листики, чем в долбицы.

Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

159. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от Alex (??), 05-Апр-11, 07:34 
Мммм... у меня тут есть рабочий элемент базы в 16 Гб объемом (сама база больше), и сложные гибкие выборки, которые (да, java-программеры могут начинать выкладывать кирпичи) _неизбежно_ требуют текстовой генерации запросов в зависимости от условий (иначе придется делать огромнейший список шаблонов запросов, да и все равно полностью от генерации не избавишься).

Куда бы мне на NoSQL податься, и сколько времени займет переписывание всего кода объемом в десятки мегабайт на любой NoSQL? Да и вообще - возможно ли это, учитывая гибкие выборки?

Ответить | Правка | Наверх | Cообщить модератору

162. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –4 +/
Сообщение от diff (??), 05-Апр-11, 07:57 
> Мммм... у меня тут есть рабочий элемент базы в 16 Гб объемом (сама база больше), и сложные гибкие выборки, которые (да, java-программеры могут начинать выкладывать кирпичи) _неизбежно_ требуют текстовой генерации запросов в зависимости от условий (иначе придется делать огромнейший список шаблонов запросов, да и все равно полностью от генерации не избавишься).
> Куда бы мне на NoSQL податься, и сколько времени займет переписывание всего кода объемом в десятки мегабайт на любой NoSQL? Да и вообще - возможно ли это, учитывая гибкие выборки?

Что значит "рабочий элемент базы"? Блоб что ли?
Если у вас такие большие блобы, что может проще воспользоваться файловой системой?
Многие забывают, что файловая система - это ведь тоже такая база данных, причем иерархическая.

Чтобы иметь возможность делать гибкие выборки, надо сначала получить возможность делать гибкие "в-борки". Чтобы гибко "доставать", нужно чтобы можно было гибко "класть".

А вообще, что бы что-то "гибко выбрать", нужно просто написать гибкий код, который гибко выбирает. Какая бы технология хранения данных не использовалась.

Keep it simple, stupid!
Чем сложнее у вас технология, тем более узкое ее назначение, и тем больше ограничений за пределами ее назначения.

А то что у вас накопились тонны кода, и вы вдруг обнаружили, что "дружили не с тем". Так это к проблематике баз данных вообще не относится - это везде так. Переписывайте, пока еще хуже не стало.

Ответить | Правка | Наверх | Cообщить модератору

272. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 09:08 
Заплатите? Перепишем.

Что такое "рабочий элемент"? Это часть базы, которая ежедневно активно используется, в тысячах запросов на запись и сотнях тысяч запросов на чтение. Все остальное сливается в архив, и используется для редких запросов.

Есть еще realtime-часть базы, которая сидит на NDB Cluster. Что-нибудь взамен ему посоветуете с аналогичным весом и масштабируемостью, или просто услышали слово NoSQL где-то, и зафанатели?

Ответить | Правка | Наверх | Cообщить модератору

280. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 07-Апр-11, 10:26 
> Заплатите? Перепишем.

Зачем мне вам платить за решение ваших проблем.

> Что такое "рабочий элемент"? Это часть базы, которая ежедневно активно используется, в тысячах запросов на запись и сотнях тысяч запросов на чтение. Все остальное сливается в архив, и используется для редких запросов.

То есть вы так это называете.

Ну и что здесь по-вашему такого принципиального делает SQL, чего нельзя сделать без SQL.

Непонимание того места, которое занимает SQL в технической структуре вашей же любимой СУБД, говорит лишь, что вы слепо верите в эту аббревиатуру.

> Есть еще realtime-часть базы, которая сидит на NDB Cluster.

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

> Что-нибудь взамен ему посоветуете с аналогичным весом и масштабируемостью, или просто услышали слово NoSQL где-то, и зафанатели?

Про NoSQL заговорил вообще не я, а я на это сразу ответил выше.

>> Нет такой системы - NoSQL. Это собирательное название. Поэтому сделать что-то "в NoSQL" нельзя.

С учетом этого, ваши заявления о моем якобы фанатизме к NoSQL лишь демонстрируют ваши низкие логические способности.
Как я могу от чего-то фанатеть, если я вам ничего не рекламировал? Это вы все рекламы требуете, потому что реклама для вас -единственный источник информации.

Ответить | Правка | Наверх | Cообщить модератору

282. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 11:01 
Толстоват, дружище. Нет денег - нет мультиков. Мне платят за фактически выполненную работу, а не за фанатизм к технологиям. Будет удобнее сделать на NoSQL - будем делать на NoSQL, тем более, что подобная система у меня уже работает в качестве кеша.
Ответить | Правка | Наверх | Cообщить модератору

286. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 07-Апр-11, 11:40 
> Мне платят за фактически выполненную
> работу, а не за фанатизм к технологиям.

и ты успешно пользуешься тем, что заказчик в твоей области ни пса не понимает. тоже правильно: когда оно упрётся в потолок — надо будет аврально переписывать, а за это можно ещё больше бабла потребовать. хотя по уму надо бы авторов приковать к компам и заставить всё переделать бесплатно.

Ответить | Правка | Наверх | Cообщить модератору

287. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 11:42 
> и ты успешно пользуешься тем, что заказчик в твоей области ни пса
> не понимает. тоже правильно: когда оно упрётся в потолок — надо
> будет аврально переписывать, а за это можно ещё больше бабла потребовать.
> хотя по уму надо бы авторов приковать к компам и заставить
> всё переделать бесплатно.

Ошибаешься. Оно пишется с расчетом на масштабируемость "вширь" - т.е. система уже сейчас построена так, что банальное добавление сервера или двух (+1 к приложению, +1 к БД) даст +50-90% (замерялось практикой) к производительности всей системы в основной массе задач.

Ответить | Правка | Наверх | Cообщить модератору

289. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 11:48 
Дабы не вызывать недоумения - уточню. Все мелкие, но особо используемые данные держатся в in-memory БД (NDB Cluster). Весь архив лежит в группе MySQL-серверов (система способна прозрачно использовать группу любого объема, делается хеш-дистрибуция). Есть NoSQL кеши, которые предназначены для массовой повторной отдачи "коротких" данных. Серверы приложений полностью кластеризованы, и работают с GlusterFS. Весь код написан так, чтобы семантические блокировки были минимальны как по рантайму, так и по количеству, местами с помощью крайне хитрых вывертов.
Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

300. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 07-Апр-11, 12:11 
дамы в восторге кидаются чепчиками, но всё равно не понимают, зачем туда затащили мускуль. наверное, потому, что если такая большая и красивая система, а буквы SQL нигде не фигурируют — то несолидно выходит.
Ответить | Правка | К родителю #289 | Наверх | Cообщить модератору

302. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 12:13 
> дамы в восторге кидаются чепчиками, но всё равно не понимают, зачем туда
> затащили мускуль. наверное, потому, что если такая большая и красивая система,
> а буквы SQL нигде не фигурируют — то несолидно выходит.

А на чем хранить 16 Гб баз? На kv, и писать самому оптимизатор запросов?

Ответить | Правка | К родителю #300 | Наверх | Cообщить модератору

306. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 07-Апр-11, 12:24 
> А на чем хранить 16 Гб баз?

такую мелочь? в чём угодно, хоть в текстовых файлах.

> и писать самому оптимизатор запросов?

каких, нафиг, запросов? а, ну да, я ж забыл: тебя укусил SQL.

кстати: откуда такой священный ужас перед «писать самому»? не понимаю совершенно. неужели ты веришь, что универсальный инструмент завсегда лучше, нежели инструмент, заточеный под конкретно твою задачу?

Ответить | Правка | К родителю #302 | Наверх | Cообщить модератору

307. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 12:25 
Ы, какой толстенький.
Ответить | Правка | К родителю #306 | Наверх | Cообщить модератору

309. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 07-Апр-11, 12:34 
> Ы, какой толстенький.

ORLY? 16 гб — это один разнесчастный сервер, у которого всё это поместится в оперативку. и ещё один для резервного хранения. какая, нафиг, разница, как оно на диске лежать будет? или вы сервера перезагружаете раз в час, для профилактики?

Ответить | Правка | К родителю #307 | Наверх | Cообщить модератору

311. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 12:41 
> ORLY? 16 гб — это один разнесчастный сервер, у которого всё это
> поместится в оперативку. и ещё один для резервного хранения. какая, нафиг,
> разница, как оно на диске лежать будет? или вы сервера перезагружаете
> раз в час, для профилактики?

Читать учитесь. 16 Гб - это рабочий объем, который как раз и сидит в оперативке (правда, не весь). Архив гораздо больше.

Ответить | Правка | К родителю #309 | Наверх | Cообщить модератору

312. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 07-Апр-11, 12:55 
> Читать учитесь. 16 Гб — это рабочий объем, который как раз и
> сидит в оперативке (правда, не весь). Архив гораздо больше.

«А на чем хранить 16 Гб баз?»
это я, что ли, спросил? из этой фразы получается однозначный вывод: 16гб — полный размер той базы, которую необходимо хранить. я же не виноват, что у тебя проблемы с формулировками. а казалось бы: занимаешься точными технологиями, должен уметь формулировать без подобных дырок.

Ответить | Правка | К родителю #311 | Наверх | Cообщить модератору

308. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 07-Апр-11, 12:33 
FYI, про «писать самому». кагбэ вот в некоей задаче используем вполне себе самописную базу, которая «сверху» вообще не выглядит базой. обычная работа с обычными объектами, у которых есть слоты. а в слотах может лежать что угодно — и ссылки на другие объекты, и всякие триггеры доступа и чёрт в ступе. а внизу — самопальный движок, который умеет накапливать статистику использования, делать динамические индексы и много других гитик. в качестве основного «верхнего» языка системы — нечто, сильно похожее на Smalltalk. добавление нового сервера в систему делается при помощи установки на новый сервер базовой софтины и пояснению этой софтине, на каких портах происходят беседы. дальше система сама включит сервер в свою структуру, решит, что с ним делать и как. fault tolerance за счёт избыточного хранения данных на нескольких машинах, натурально, так что если сервер отвалился — система удивится, но не сломается.

серверов, правда, не так много пока — меньше двух десятков. проблемы с масштабируемостью на сотни серверов мы видим, но решать в рамках именно этой системы вряд ли будем, потому что такая задача появится оооооочень нескоро.

Ответить | Правка | К родителю #302 | Наверх | Cообщить модератору

313. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 07-Апр-11, 13:19 
> Толстоват, дружище. Нет денег - нет мультиков. Мне платят за фактически выполненную работу, а не за фанатизм к технологиям.

Дворникам тоже платят за фактическую работу. И что?
Еще не известно, что вы там на своей работе делает. Вашу работу здесь никто не видит.

И судя по всему ваша предполагаемая работа - это вы считаете убийственным аргументом.
Так же как то, что много чего на SQL "работает".

Из этого вы делаете вывод, что все остальное по-вашему "теория". Только потому, что вы больше ничего не знаете.

> Будет удобнее сделать на NoSQL - будем делать на NoSQL, тем более, что подобная система у меня уже работает в качестве кеша.

Еще раз. Я уже сказал. Нет такой технологии NoSQL. Поэтому делать что-то "на NoSQL" невозможно.

Ответить | Правка | К родителю #282 | Наверх | Cообщить модератору

257. "PHP-транслятор HipHop позволил Facebook использовать в..."  –1 +/
Сообщение от anonymous (??), 06-Апр-11, 16:21 
> Мммм… у меня тут есть рабочий элемент базы в 16 Гб объемом

тебе забыли рассказать про обычные файлы?

> и сложные гибкие выборки

это что?

> _неизбежно_ требуют текстовой генерации запросов в зависимости
> от условий (иначе придется делать огромнейший список шаблонов запросов, да и
> все равно полностью от генерации не избавишься).

только не понятно, зачем генерить текст, который компилятор потом «перегенерит» во внутренний язык базы, если можно без этого обойтись? да, возможно (возможно!) придётся один раз написать систему работы с этим (задачи не знаю, беру наиболее общий случай).

> Куда бы мне на NoSQL податься

что такое «NoSQL»? и какие задачи? систем много, заточены под разное.

> и сколько времени займет переписывание всего
> кода объемом в десятки мегабайт на любой NoSQL?

наличие многомегабайтного legacy — не проблемы db engine.

> Да и вообще — возможно ли это, учитывая гибкие выборки?

конечно, нет — ты ещё простым файлам не обучился (ты сам это сказал), куда тебе в остальное-то?

Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

273. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 09:12 
> тебе забыли рассказать про обычные файлы?

Конечно забыли. Я знаю, "тормоза придумали трусы"... это по аналогии с "SQL придумали лохи". Задача гибкого realtime-биллинга "обычными файлами" не решается при условии необходимости оперативности выборок (а не "просуммировал-забыл").

>> и сложные гибкие выборки
> это что?

Это? Это возможность получения вагона универсальных отчетов из сырых данных, при том, что конкретную направленность каждого конкретного отчета, который захочет организация, предусмотреть заранее сложно. С клиентами проще, там все аггрегируется. А вот во внутренней системе не все так просто.

> только не понятно, зачем генерить текст, который компилятор потом «перегенерит»
> во внутренний язык базы, если можно без этого обойтись? да, возможно
> (возможно!) придётся один раз написать систему работы с этим (задачи не
> знаю, беру наиболее общий случай).

Ну да, пишите, все равно после выяснится, что вы изобрели колесо, ака написали SQL xD

> наличие многомегабайтного legacy — не проблемы db engine.

Угумс. Только непонятен нездоровый фанатизм по поводу db engine. Если SQL справляется - зачем городить огород?

> конечно, нет — ты ещё простым файлам не обучился (ты сам это
> сказал), куда тебе в остальное-то?

Толсто.


Ответить | Правка | Наверх | Cообщить модератору

283. "L"  +/
Сообщение от anonymous (??), 07-Апр-11, 11:30 
> Задача гибкого realtime-биллинга «обычными файлами» не решается при условии
> необходимости оперативности выборок (а не «просуммировал-забыл»).

ура! наконец-то мы услышали что-то про предметную область. прогресс, аднака.

> Это? Это возможность получения вагона универсальных отчетов из сырых данных, при том,
> что конкретную направленность каждого конкретного отчета, который захочет организация,
> предусмотреть заранее сложно. С клиентами проще, там все аггрегируется. А вот
> во внутренней системе не все так просто.

и? внизапна! это не уникальная задача. но тут, конечно, конкретно смотреть надо.

> Ну да, пишите, все равно после выяснится, что вы изобрели колесо, ака
> написали SQL xD

забавно, почему когда я писал подобное — у меня не получался SQL? опять же. биллинг? рилтайм? да там должны быть такие потоки данных, что SQL просто удавится.

> Угумс. Только непонятен нездоровый фанатизм по поводу db engine. Если SQL справляется
> — зачем городить огород?

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

хотя с другой стороны — легаси крап имеет свойство накапливаться, и однажды палок и скотча может не хватить. тут главное — успеть уволиться до того, как полный пэ настанет.

> Толсто.

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

Ответить | Правка | Наверх | Cообщить модератору

285. "L"  +/
Сообщение от AlexAT (ok), 07-Апр-11, 11:37 
> опять же. биллинг? рилтайм? да там должны быть такие потоки данных,
> что SQL просто удавится.

Ну... я не знаю, быть может дело в чем-то другом, а не в SQL. Поток данных действительно громадный (как уже говорил - рабочий объем базы порядка 16 Гб, остальное тупо валяется в архиве и специализированных кешах, и ждет, пока попросят отчет за большой период).

Ответить | Правка | Наверх | Cообщить модератору

288. "L"  +/
Сообщение от anonymous (??), 07-Апр-11, 11:46 
а SQL помогает скорость потока притормозить. а то лошадки устанут. собственно, если люди, которые хотят отчёты, сами не пишут их на SQL (не, чо, я и таких манагеров видел), то на кой шиш там вообще SQL сдался?

хотя я, скорее всего, понимаю. оно ВНИЗАПНА! выросло из системы, которую по-быстрому настрочили на первых попавшихся под руку инструментах. система заработала, и дальше попёрло: «некогда переделывать, копать надо!» «но это же прототип…» «да пофигу! копай давай, прототип-шмототип, умник нашёлся…»

зыж тьфу, йопт! когда это я успел заголовок в «L» переделать? я не видел эту вашу десу ното!

Ответить | Правка | Наверх | Cообщить модератору

284. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 07-Апр-11, 11:36 
кстати. была у нас, помнится, задача, где данные поступали быстрее, чем винты успевали их записывать. тащемта она, конечно, одинаково решается что с SQL, что без, но SQL добавляет дополнительный геморрой. заказчик выбрал артель имени швондера, бедняга. которые махали у него перед носом «стандарным SQL». не справились.

мы, впрочем, тоже не справились, но это потому, что отказались за швондерами объедки подбирать. хотя было чертовски интересно это сделать, даже прикидывали, как. но понты дороже.

Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

172. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от zerotemail (??), 05-Апр-11, 11:34 
ну да, транзакционная система управления данными на несколько (десятков) тысяч конкурирующих пользователей с одновременной сложной отчётностью, высокой критикой и определёнными параметрами RPO и RTO (времени простоя и допустимых потерь) реализуется на всяком там NoSQL
-
не, парни, для этого есть правильные инструменты типа Oracle. У NoSQL своя ниша, но вот так огульно "реляционная модель умерла" ... глупости
Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

174. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –1 +/
Сообщение от diff (??), 05-Апр-11, 11:43 
Еще раз, для тех кто в танке. NoSQL - это всего лишь "нет SQL".

> ну да, транзакционная система управления данными на несколько (десятков) тысяч конкурирующих пользователей с одновременной сложной отчётностью, высокой критикой и определёнными параметрами RPO и RTO (времени простоя и допустимых потерь) реализуется на всяком там NoSQL
> -
> не, парни, для этого есть правильные инструменты типа Oracle. У NoSQL своя ниша, но вот так огульно "реляционная модель умерла" ... глупости

Какое по-вашему отношение имеют транзакции к SQL и к реляционной модели вообще?

Почему вы считаете, что все перечисленные вами достоинства не могут быть реализованы в системе без SQL и реляционной модели. Как это все по-вашему взаимосвязано? Кроме того факта, что в какой-то исторический период это все оказалось в одной куче.

Вот так обычно бывает, когда человек начинает мыслить в стереотипах одного какого-то языка.

Ответить | Правка | Наверх | Cообщить модератору

178. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от ананим (?), 05-Апр-11, 12:06 
ёптить. а если так - ну предложите другое не менее законченное решение без_сиквела, но с транзакциями, триггерами и пр, и пр.
и ещё так, чтобы любому жабисту было понятно. и чтоб не бегать за каждым и сопли не подтирать.

>Вот так обычно бывает, когда человек начинает мыслить в стереотипах одного какого-то языка.

во-во.
но и пистеть - не мешки ворочить.

Ответить | Правка | Наверх | Cообщить модератору

180. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –1 +/
Сообщение от diff (??), 05-Апр-11, 12:15 
> ёптить. а если так - ну предложите другое не менее законченное решение без_сиквела, но с транзакциями, триггерами и пр, и пр.

Для начала проследите ход вашей мысли.

Что по-вашему мешает реализовать транзакции и триггеры без SQL. И почему вы так уверены, что такие "законченные решения" уже давным-давно не реализованы, чтобы мне была необходимость что-то здесь предлагать.

И вообще, какое отношение имеют триггеры и транзакции к реляционной модели, о которой речь шла в начале.

> и ещё так, чтобы любому жабисту было понятно. и чтоб не бегать за каждым и сопли не подтирать.

Я "жабой" не пользуюсь, так что мне как-то параллельно, что им понятно, а что не понятно.

Хотя опять-таки, что по-вашему мешает, это сделать на той же "жабе", и почему вы думаете, что опять-таки давно уже не сделано?

Ответить | Правка | Наверх | Cообщить модератору

184. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от Aqueeloneemail (?), 05-Апр-11, 12:55 
В общем поддерживая то, про что Вы говорите, замечу следующее.

Цитаты из Википедии:
-----цитата 1--------
SQL (ˈɛsˈkjuˈɛl; англ. Structured Query Language — «язык структурированных запросов») — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных.
SQL основывается на реляционной алгебре.
----конец цитаты----
-----цитата 2--------
Реляционная алгебра — формальная система манипулирования отношениями в реляционной модели данных. Существует в двух несколько различающихся вариантах:
алгебра Кодда (Э. Кодд, 1970)
алгебра A (К. Дейт, Х. Дарвен)
Наряду с реляционным исчислением является способом получения результирующего отношения в реляционной модели данных.
---------------------

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

Потому, Вы можете отказаться от SQL. Причем очень часто под ним понимается вполне конкретная спецификация или реализация.
Но реляционность, то есть работа с множеством посредством формализованых для этого множества операторов ... это весьма глубоко.
Многие подходы к БД, которые себя не позиционируют как SQL, таки являются реляционными.
Хороший пример тому --- MangoDB.

Ответить | Правка | Наверх | Cообщить модератору

197. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –2 +/
Сообщение от diff (??), 05-Апр-11, 14:32 
> Реляционная алгебра — формальная система манипулирования отношениями в реляционной модели данных. Существует в двух несколько различающихся вариантах:
> алгебра Кодда (Э. Кодд, 1970)
> алгебра A (К. Дейт, Х. Дарвен)
> Наряду с реляционным исчислением является способом получения результирующего отношения в реляционной модели данных.

Я в курсе.

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

А вот и нет. Традиционный ООП не имеет отношения ни к реляционной алгебре ни к реляционному исчислению.
Вы допустили такую грубую ошибку, потому что плохо знаете, что такое алгебры и исчисления вообще.

> Потому, Вы можете отказаться от SQL. Причем очень часто под ним понимается вполне конкретная спецификация или реализация.

Естественно, потому что это язык и не более.

> Но реляционность, то есть работа с множеством посредством формализованых для этого множества операторов ... это весьма глубоко.

А я копал глубоко. Гораздо глубже, чем вы себе представляете.

Поэтому вижу, что вы снова ошибаетесь. Вы плохо представляете себе, что такое множества, и как теория множеств связана с реляционной теорией.
Так вот, это неверное утверждение: "реляционность - работа с множеством посредством формализованых для этого множества операторов".

> Многие подходы к БД, которые себя не позиционируют как SQL, таки являются реляционными.

И здесь я тоже в курсе.
Я нигде не утверждал, что реляционные системы обязаны быть на SQL.

Более того, если бы внимательно прочитали один из первых моих постов, то заметили бы, что я сказал, что сам SQL, строго говоря реляционной системой не является. Поскольку не удовлетворяет требованиям ни рел. алгебры ни рел. исчисления.
В том и его проблема, что ни бэ, ни мэ.

> Хороший пример тому --- MangoDB.

А вы уверены, что MongoDB таки является реляционной?
Ну если конечно вы считаете все объектные системы реляционными - можете продолжать так считать.

Хотя лучше бы вам поучить предмет.

Ответить | Правка | Наверх | Cообщить модератору

246. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –1 +/
Сообщение от Aqueeloneemail (?), 06-Апр-11, 12:22 
Корректность от Вашего ответа "так и прёт"!
Ежели со мной не согласны -- то хоть почитайте грандов.
Хорошая статья здесь -- http://citforum.ru/database/articles/manifests/art_28_4_2.shtml
на базе труда из книги Дейта и Дарвена “Основы будущих систем баз данных: третий манифест”.

А меряться у кого длинее со мной не нада...

<<Хотя лучше бы вам поучить предмет.
ВЗАИМНО!

Ответить | Правка | Наверх | Cообщить модератору

256. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 06-Апр-11, 15:57 
> Корректность от Вашего ответа "так и прёт"!
> Ежели со мной не согласны -- то хоть почитайте грандов.

Если с вами кто-то не согласен - он имеет на это право. Также как вы имете право быть несогласным со мной.

Только ошибки и несогласие - это принципиально разные вещи.

Гранды тоже бывают разные. Некоторые добиваются свими способностями, а некоторые политико-экономическими методами. Хотя для этого тоже нужны бывают способности, но другие.

> Хорошая статья здесь -- http://citforum.ru/database/articles/manifests/art_28_4_2.shtml на базе труда из книги Дейта и Дарвена “Основы будущих систем баз данных: третий манифест”.

Вы рассчитывали, что я не знаю о Третьем манифесте. Должен вас огорчить.
Статей есть много хороших и разных, и я их, можете представить, много прочел, а также и книги. И самого Дейта я читал, не переживайте.

Подкину вам другую свежую мысль. Из того, что я вами не согласен, еще не следует, что не читал то же, что читали вы. Из этого следует, что я понял это не так, как вы.

Поэтому вопрос плавно перетекает в следующий: насколько правильно понято то, что прочитано, а не что именно прочитано.

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

> А меряться у кого длинее со мной не нада...

Я с вами ничем не мерялся, я вам указал на конкретные ваши ошибки, а это разные вещи.

Ответить | Правка | К родителю #246 | Наверх | Cообщить модератору

182. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от злой мамонт (?), 05-Апр-11, 12:44 
Вы не правы, NoSQL означает "Не только SQL" - Not Only SQL.
Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

183. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –1 +/
Сообщение от diff (??), 05-Апр-11, 12:54 
> Вы не правы, NoSQL означает "Не только SQL" - Not Only SQL.

Знаете, я с вами в этом соглашусь.

Только я сам непосредственно про это NoSQL вопрос не поднимал.
Я говорил про проблемы реляционной модели и SQL.

Это же не мои проблемы, что не которые считают, что если не SQL, то непременно "Not Only SQL". Если их на SQL постоянно циклит.

Ответить | Правка | Наверх | Cообщить модератору

186. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от Aqueeloneemail (?), 05-Апр-11, 12:59 
>> Вы не правы, NoSQL означает "Не только SQL" - Not Only SQL.
> Знаете, я с вами в этом соглашусь.
> Только я сам непосредственно про это NoSQL вопрос не поднимал.
> Я говорил про проблемы реляционной модели и SQL.
> Это же не мои проблемы, что не которые считают, что если не
> SQL, то непременно "Not Only SQL". Если их на SQL постоянно
> циклит.

Но если не реляционная алгебра, то что?
Ведь пока рассматриваются варианты -- или Алгебра Кодда, или Алгебра А.
Все это -- реляционная алгебра.
иного... ну я, например, пока не вижу!

Ответить | Правка | Наверх | Cообщить модератору

198. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –1 +/
Сообщение от diff (??), 05-Апр-11, 14:38 
> Но если не реляционная алгебра, то что?

Ну вы же сами написали выше - например, объекты. Хотя есть и другие более интересные варианты. Поскольку ООП - это скорее такой ширпотреб, для тех, кто не любит загружаться теорией.

Хотя вы же считатее, что ОО-системы по-вашему то же самое, что и реляционные.
Однако это уже сугубо ваши проблемы.

> Ведь пока рассматриваются варианты -- или Алгебра Кодда, или Алгебра А.

Где "пока" рассматриваются?

> Все это -- реляционная алгебра.

Логично, что и та, и другая алгебры - все это реляционные алгебры. Если это действительно было бы всё.

> иного... ну я, например, пока не вижу!

Расширяйте кругозор!

Ответить | Правка | Наверх | Cообщить модератору

247. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от Aqueeloneemail (?), 06-Апр-11, 12:31 
>[оверквотинг удален]
> Хотя вы же считатее, что ОО-системы по-вашему то же самое, что и
> реляционные.
> Однако это уже сугубо ваши проблемы.
>> Ведь пока рассматриваются варианты -- или Алгебра Кодда, или Алгебра А.
> Где "пока" рассматриваются?
>> Все это -- реляционная алгебра.
> Логично, что и та, и другая алгебры - все это реляционные алгебры.
> Если это действительно было бы всё.
>> иного... ну я, например, пока не вижу!
> Расширяйте кругозор!

Интересно, а по теме Вы писать-то умеете?
Основная идея ООП -- объект "сам в себе".
То есть -- этот объект является данными, которые "по простому" имеют инструмент работы с самими собой.
Реляционность базы данных -- это и есть поддаваемость работе с ограниченым (конечным) числом операторов -- чо их как раз и роднит с ООП.

И вообще -- почаще читайте материальную часть!

Ответить | Правка | Наверх | Cообщить модератору

254. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 06-Апр-11, 15:20 
> Интересно, а по теме Вы писать-то умеете?

Стоит указать некоторым на их ошибки, как сразу начинают жаловаться, что якобы было не по теме.
Тему ООП подняли вы, а не я.

> Основная идея ООП -- объект "сам в себе".

Ну вот снова. Нет, это не "основная идея" ООП. Это скорее философия Канта, что вообще-то не то же самое, что ООП.
Основные идеи ООП формулируются гораздо более четко.

> То есть -- этот объект является данными, которые "по простому" имеют инструмент работы с самими собой.

Данные - это тоже объект(ы). Вы же сами сказали про "сам в себе".
Если не запостулировано понятия объекта, то нельзя говорить о данных.

А если понятие "данных" первичнее понятия объекта, то о какой объектной системе может идти речь?
Точнее в начале даже что-то начнет получаться, но стоит чуть повысить уровень абстракции - и получите очень тупые противоречия.

Хотя для быдлокодеров вполне достаточно, поэтому в PHP, SQL и других быдлокодерские системах реализована ущербная объектная модель по принципу "и так сойдет", а все что не срослось, устраняется "методом напильника".

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

> Реляционность базы данных -- это и есть поддаваемость работе с ограниченым (конечным) числом операторов -- чо их как раз и роднит с ООП.

В прошлый раз вы определили реляционность так: "реляционность - работа с множеством посредством формализованых для этого множества операторов".
Теперь, значит, вот эдак, и снова неверно.

> И вообще -- почаще читайте материальную часть!

Ну здесь вы уже просто пытаетесь подражать мне.

А мне заранее известно, где вы ошибетесь в следующий раз.
И это даже не моя заслуга. Потому что многие уже этим путем прошли, а вы еще не подступились.

Ответить | Правка | К родителю #247 | Наверх | Cообщить модератору

204. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от Sw00p aka Jerom (?), 05-Апр-11, 16:45 
Уважаемый

знаете в чём минус SQl ? - невозможно создавать структуры с неограниченным количеством вложенности

приходиться костылями и рукурсиями всё доставать - или как предлагают решение - сдампить всю таблицу и построить дерево )))))))))

Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

274. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 09:14 
> Это же не мои проблемы, что не которые считают, что если не
> SQL, то непременно "Not Only SQL". Если их на SQL постоянно
> циклит.

Увы, это не наши проблемы, что вы теоретик. Как дойдете до практики - там и поговорим.

Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

279. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 07-Апр-11, 10:07 
>> Это же не мои проблемы, что не которые считают, что если не SQL, то непременно "Not Only SQL". Если их на SQL постоянно циклит.
>
> Увы, это не наши проблемы, что вы теоретик. Как дойдете до практики - там и поговорим.

SQL - это просто такой язык, причем не лучшего качества. А вовсе не "теория", как вам кажется. Хотя для некоторых это религия.

Вы, значит, убеждены что просто взять и не использовать этот язык при разработке СУБД - это по-вашему практически трудно-осуществимо, и это по-вашему лишь теория.
И что-то по-вашему мешало технически и практически, кроме чьих-то стереотипов, еще с самого начала, параллельно с развитием SQL-систем, развиваться альтернативным технологиям.

Просто вы об этом ничего не знаете. Вот когда узнаете, тогда и поговорим.

Ответить | Правка | Наверх | Cообщить модератору

290. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 07-Апр-11, 11:52 
> Увы, это не наши проблемы, что вы теоретик. Как дойдете до практики
> - там и поговорим.

вот интересно, с каких пор "теоретик" стало ругательством? ты, следует полагать, теоретические труды принципиально не читаешь, чтобы не запомоиться? O_O

Ответить | Правка | К родителю #274 | Наверх | Cообщить модератору

291. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 11:54 
> вот интересно, с каких пор "теоретик" стало ругательством? ты, следует полагать, теоретические
> труды принципиально не читаешь, чтобы не запомоиться? O_O

Да нет, я просто предпочитаю теорию в практику воплощать. А на практике есть уйма нюансов, которые голым теоретикам и не снились даже.

Ответить | Правка | Наверх | Cообщить модератору

294. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 07-Апр-11, 12:01 
> Да нет, я просто предпочитаю теорию в практику воплощать. А на практике
> есть уйма нюансов, которые голым теоретикам и не снились даже.

(задумчиво) так кто ж заставляет делать «точно по книге»? теория — она нужна не для того, чтобы её тупо копипастить в реал, а чтобы на её основе делать своё. а иначе получатся крайности… один узнал про «нормализацию баз», и как видит специально денормализованные базы, у него припадок трясучей. другой вообще считает, что «теория бд — чушь на постном масле», и припадки трясучей от его баз у всех остальных…

Ответить | Правка | К родителю #291 | Наверх | Cообщить модератору

295. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 12:04 
> (задумчиво) так кто ж заставляет делать «точно по книге»? теория — она
> (skipped)

Так вот и я о том, что теоретики такие теоретики.

Ответить | Правка | К родителю #294 | Наверх | Cообщить модератору

297. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 07-Апр-11, 12:06 
> Так вот и я о том, что теоретики такие теоретики.

а ты что, ожидаешь на основе тех куцых кусочков информации, которые из тебя клещами вытащили, какого-то решения, «приближенного к практике»? O_O

Ответить | Правка | К родителю #295 | Наверх | Cообщить модератору

299. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 12:09 
> а ты что, ожидаешь на основе тех куцых кусочков информации, которые из
> тебя клещами вытащили, какого-то решения, «приближенного к практике»? O_O

Хы, в общем и целом ничего от тебя не ожидаю, просто покормить решил xD

Ответить | Правка | К родителю #297 | Наверх | Cообщить модератору

301. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 07-Апр-11, 12:13 
> Хы, в общем и целом ничего от тебя не ожидаю, просто покормить
> решил xD

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

Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

303. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 12:14 
> когда по сути сказать нечего, есть беспроигрышный ход: объявить, что оппонент —
> простое трололо, и на самом деле ты его просто кормишь. это
> очень неоригинальный ход, к которому прибегают от беспомощности.

Ну да, равно как и перейти на личности оппонента в первом же посте... xD

Ответить | Правка | К родителю #301 | Наверх | Cообщить модератору

304. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 07-Апр-11, 12:20 
> Ну да, равно как и перейти на личности оппонента в первом же
> посте… xD

а чем тебя смущает «переход на личности»? какая разница, в какой форме ведётся дискуссия, если там есть рациональное зерно? IRL я вообще матом разговариваю.

а в данной беседе как обычно пришлось играть в гестапо, чтобы из тебя хоть какие-то подробности вытащить.

Ответить | Правка | К родителю #303 | Наверх | Cообщить модератору

305. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 12:21 
> а в данной беседе как обычно пришлось играть в гестапо, чтобы из
> тебя хоть какие-то подробности вытащить.

О чорд. Люди работой заняты, а форумные тролли все еще играют.

Ответить | Правка | К родителю #304 | Наверх | Cообщить модератору

310. "PHP-транслятор HipHop позволил Facebook использовать в..."  +1 +/
Сообщение от anonymous (??), 07-Апр-11, 12:37 
> О чорд. Люди работой заняты, а форумные тролли все еще играют.

а-а-а, ты их тех, которые, как тут где-то писалось, «по 8 часов в день 5 дней в неделю пилят-пилят-пилят»? ну, «работай» тогда, кто ж запретить может.

Ответить | Правка | К родителю #305 | Наверх | Cообщить модератору

187. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от zerotemail (??), 05-Апр-11, 13:02 
> Еще раз, для тех кто в танке. NoSQL - это всего лишь "нет SQL".

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

Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

199. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –2 +/
Сообщение от diff (??), 05-Апр-11, 14:47 
> я говорил не про теоретического коня в неизвестном будущем,

Ну я же не виноват, что для вас теоретические основы информатики и компьютерных систем - что для вас это "конь в неизвестном будущем".

Если вы чего-то не знаете, это еще не обязательно должно быть в будущем.

> а о том, что на текущий момент сложилась практика использования определённых технологий и инструментария для практического решения определённого круга сурьёзных задач

У кого-то сложились одни практики, у кого-то другие. Просто те, что вам известны - это далеко не все, что есть на свете.

"Теория без практики - мертва, практика без теории - слепа".

Просто вы предпочитаете слепую практику, это ваш выбор.

А без соотвествующих теорий не было бы разработано ни процессоров, ни компиляторов, ни ОСей, ни тех же движков СУБД, в том числе реляционных.

> -
> и хотя бы поэтому хоронить реляционную модель рано

Ну так ее никто и не хоронит. Пока у нее будут последователи, она будет жива. Просто она зашла в тупик. Именно в практический тупик.

Ответить | Правка | Наверх | Cообщить модератору

228. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от zerotemail (ok), 05-Апр-11, 23:23 

> Ну я же не виноват, что для вас теоретические основы информатики и компьютерных систем - что для вас это "конь в неизвестном будущем"
> Если вы чего-то не знаете, это еще не обязательно должно быть в будущем.
> У кого-то сложились одни практики, у кого-то другие. Просто те, что вам известны - это далеко не все, что есть на свете
> "Теория без практики - мертва, практика без теории - слепа". Просто вы предпочитаете слепую практику, это ваш выбор
> А без соотвествующих теорий не было бы разработано ни процессоров, ни компиляторов, ни ОСей, ни тех же движков СУБД, в том числе реляционных

как бы не обидеть ... слишком вольно толкуете чужие слова, а мной сказано только то, что сказано, манера вольного толкования и добавления своих выводов не проканает, умствуете и пытаетесь выпятить бессмысленные "фигуры речи"

> Ну так ее никто и не хоронит. Пока у нее будут последователи, она будет жива. Просто она зашла в тупик. Именно в практический тупик.

опять же известно какая нелюдь пытается говорить за всех (за народ и т.п.) Не уподобляйтесь, или будут делать заслуженные замечания по сути ваших высказываний. Никакого тупика нет, технология на своём месте. пример простой - лопата не меняется века и вполне себе находит применение

Ответить | Правка | Наверх | Cообщить модератору

234. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 06-Апр-11, 04:28 
Ну вы вместо того, чтобы жаловаться, взяли бы и показали, как ваши слова следовало бы правильно толковать.

С другой стороны, о каком "толковании" ваших слов может идти речь, если я привел цитаты ваших высказываний слово-в-слово.
Вы черным по белому заявили, что вы считаете нереляционные технологии "теоретическим конем в неизвестном будущем". И остальное в том же духе. Все тексты в наличии.

И что вас сейчас не устраивает? Вы уже так не считаете, как заявляли ранее? И хотите сказать, что имели в виду якобы совсем-совсем другое?

Ответить | Правка | Наверх | Cообщить модератору

249. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от Aqueeloneemail (?), 06-Апр-11, 12:42 
> Ну вы вместо того, чтобы жаловаться, взяли бы и показали, как ваши
> слова следовало бы правильно толковать.
> С другой стороны, о каком "толковании" ваших слов может идти речь, если
> я привел цитаты ваших высказываний слово-в-слово.
> Вы черным по белому заявили, что вы считаете нереляционные технологии "теоретическим конем
> в неизвестном будущем". И остальное в том же духе. Все тексты
> в наличии.
> И что вас сейчас не устраивает? Вы уже так не считаете, как
> заявляли ранее? И хотите сказать, что имели в виду якобы совсем-совсем
> другое?

Некорректность с Вашей стороны -- это переход на личности.
Не Вам судить кто что и на сколько знает.
Я понимаю -- когда фактов не хватает, легко бросить -- "Вы этого не знаете, идите учитесь..."...
Это возможно в кругу Ваших почитателей. Но здесь, думается, не корректно.

Ответить | Правка | Наверх | Cообщить модератору

255. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 06-Апр-11, 15:26 
Так как вы здесь по теме все равно ничего не сказали, отвечу вам следующее.

Если вы считаете, что проблема только в этом, а не в тех ошибках, которые вы допускаете - тогда вам не о чем беспокоиться.

С другой стороны, если бы проблема была действительно в этом, то это моя проблема. Почему тогда вы о ней беспокоитесь?

Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

315. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от zerotemail (ok), 08-Апр-11, 21:25 
> С другой стороны, о каком "толковании" ваших слов может идти речь, если
> я привел цитаты ваших высказываний слово-в-слово.
> Вы черным по белому заявили, что вы считаете нереляционные технологии "теоретическим конем в неизвестном будущем"

диф. улыбку вы заслужили, особенно после прочтения ваших постов во всей дискуссии. но даже в посте на который я отвечаю ловко приписали мне дополнительные слова и выводы

> И остальное в том же духе. Все тексты в наличии.

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

Ответить | Правка | Наверх | Cообщить модератору

316. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 09-Апр-11, 09:22 
>> Вы черным по белому заявили, что вы считаете нереляционные технологии "теоретическим конем в неизвестном будущем"
>
> диф. улыбку вы заслужили, особенно после прочтения ваших постов во всей дискуссии.

Если вы до сих пор убеждены, что нереляционные базы данных - это "теоретическим конем в неизвестном будущем" - тогда улыбаться является вашем правом. Я вам улыбаться никак не пытался запрещать.
Однако хорошо смеется тот, кто смеется последним.

> но даже в посте на который я отвечаю ловко приписали мне дополнительные слова и выводы

Как я мог вам что-то приписать, если я цитаты ваших слов приводил. Ну так вы поясните, что же вы имели в виду на самом деле. Или снова боитесь опозориться?

Так по-вашему вы не заявляли, что нереляционные базы данных - это "теоретический конь в неизвестном будущем"?
И по вашему вы не упоминали транзакций, как будто они имеют отношение к тому, реляционная БД или нереляционная?
И по-вашему вы не считали, что якобы существует такая технология NoSQL, непосредственно на которой можно что-то сделать?

И многое другое, от чего вы сейчас пытаетесь откреститься.

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

Такие слова, как эти, можно говорить абсолютно обо всем. Очень удобно. Предмет знать для этого не нужно.

Ответить | Правка | К родителю #315 | Наверх | Cообщить модератору

317. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 09-Апр-11, 09:49 
> думаю, вы не учитываете
> инерцию уже сложившегося, а также тот факт, что информационные технологии существуют
> не в вакууме - они являются не самым значительным явлением, задача
> которого - обеспечить отдельные второстепенные потребности человечества и паразитической
> надстройки над ним - современного социума. из этого много следует

какой отличный образчик словоблудия!

Ответить | Правка | К родителю #315 | Наверх | Cообщить модератору

248. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от Aqueeloneemail (?), 06-Апр-11, 12:39 
> Ну так ее никто и не хоронит. Пока у нее будут последователи,
> она будет жива. Просто она зашла в тупик. Именно в практический
> тупик.

Если послушать грандов по этой теме -- Дейта и Дарвена,
то в тупик зашла именно реализация всего этого, базирующаяся на "втором маницесте".
Именно потому и издан "третий манифест".

Подробно цитата: (взять отсюда -- http://citforum.ru/database/articles/manifests/art_28_4_2.shtml )
----------------------
Прежде всего, заметим, что это второе издание, вышедшее в свет в 2000 г. Первое издание было опубликовано в 1998 г. под названием “Основы объектно/реляционных баз данных” [19]. Вот что пишут Д&Д по поводу изменения названия в предисловии ко второму изданию [20]: “Название первой редакции характеризовало Манифест как “основание объектно/реляционных баз данных”. Хотя эта характеристика была точной, она не была достаточной. Теперь мы считаем Манифест (как, впрочем, было всегда) основанием будущих баз данных вообще – включая, например, базы данных, содержащие темпоральные данные, и базы данных, используемые в связи с World Wide Wed .”

Однако, как кажется,  более вероятными причинами для смены названия были следующие обстоятельства:

Название первого издания могло вводить в заблуждение читателей, не слишком хорошо знакомых с подходом Д&Д. Термин “объектно-реляционные системы баз данных” достаточно давно закрепился за технологией, следующей идеям Второго манифеста и реализованной в разных формах в продуктах Informix , Oracle и IBM . Видимо, при выборе названия для первого издания своей книги Д&Д стремились подчеркнуть, что идеи именно Третьего манифеста могут привести к достижению тех целей, которые ставили перед собой создатели Второго манифеста.
Но независимо от того, присутствие слова “объектно” в названии первого издания книги противоречило явственно высказываемому Д&Д отношению к объектной технологии в области баз данных. Д&Д постоянно подчеркивают путаницу и туманность, связанные с использованием термина “объект” в “объектно-ориентированном мире”. Сами они используют (или стремятся использовать) это слово только в неформальном смысле. Но в этом случае неясно, как следует трактовать названием первого издания. Основы чего предлагают авторы?
----конец цитаты-----

Думается, с отцами-основателями Алгебры А и вообще реляционной модели баз данных Вы спорить не будете? Или тоже пошлете их к Вам на курсы повышения квалификации?

Ответить | Правка | К родителю #199 | Наверх | Cообщить модератору

266. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 06-Апр-11, 17:35 
По поводу "грандов", Дейта и Манфеста я уже высказался здесь:
https://www.opennet.ru/openforum/vsluhforumID3/76066.html#256

Только добавлю к этому.

Вот вы большую часть данного поста рекламировали мне Манифесты и Дейта. Я уже сказал в том посте, ссылку на который я привел, что я их читал.

Но дело не в этом. Интересен ход вашей мысли. А именно, как вы обращаетесь и источниками и информацией.

Большинство людей считают, что осведомленность о..., а уж тем более и прочтение некоторого источника гарантирует им знание той информации, которая была в источнике заключена.
То есть для ни цикл познания представлен прямолинейно - "прочитал-знаю", примерно как "откусил-проглотил(сыт)".

Однако некоторые люди не считают, что этого достаточно - прочитать некоторый источник. Они считают, что необходимо еще и понять прочитанное. То есть сам факт прочтения гарантией знаний для них не является. И цикл познания у них выглядит несколько иначе - "прочитал-понял-знаю", примерно как "откусил-разжевал-проглотил(сыт)".

Можете конечно опять жаловаться на переходы на личности. Но тут есть принципиальный психологический момент.

Вас выдает то, как вы говорите (так же как и некоторые другие тут), а именно:
"Если вы не _согласны_ со мной - прочитайте".

В товремя как я и то меньшинство, к которому я себя отношу, говорят по другому: "Вы совершили такую-то и такую-то ошибку, хотите читайте, хотите нет, можете вообще ничего не читать и остаться со мной несогласным".

Поскольку для этого меньшинства сама информация важнее источника. Тогда как для большинства источник важнее информации.

Однако, я готов перечитать те источники, если вы конкретно мне покажете, в чем я по-вашему ошибся. А не только на тот факт, что я с вами не согласен.

А факт несогласия объясняется тем, что хоть мы и прочли с вами одинаковые источники, мы почему-то поняли смысл по-разному. А вот кто понял правильно - это вопрос отдельный.

Так вот обычно и бывает. Читает человек в течении нескольких десятков лет какие-то источники, а потом вдруг - бац! - и оказывается, что он несколько десятков лет понимал их неправильно. И что ему делать? Перечитывать все заново в течении следующих нескольких десятков лет?

--------------------------------------------

Возвращаясь к теме.
Вы коснулись объектно-реляционной модели.

Но вы настолько увлеклись рекламой Дейта и Манифестов, и фактом моего несогласия с вами, что забыли четко сформулировать, что же вы хотели доказать, кроме якобы необходимости мне это прочитать.

Хотя я могу заранее догадаться, к чему вы клоните, говоря про объектно-реляционную модель.
Так же как я заранее знаю, где вы ошибетесь.
Но все-таки, будьте так любезны и сформулируйте свою точку зрения до конца, и что именно вы имели в виду, упоминая объектно-реляционную модель.

---------------------------------------------

> Думается, с отцами-основателями Алгебры А и вообще реляционной модели баз данных Вы спорить не будете? Или тоже пошлете их к Вам на курсы повышения квалификации?

С отцами-основателями я может спорить и не буду. Но это еще не гарантия, что я не буду, спорить с вами, поскольку, как я уже сказал, пока нет никаких гарантий, что вы сами правильно понимаете "отцов-основателей".

Кроме того, как быть с тем фактом, что сами "отцы-основатели" спорят друг с другом?
Если вы знаете содержание Манифестов, то там одни "отцы-основатели" критикуют других "отцов-основателей".

Из этого можно сделать вывод, что "отцы-основатели" - они не боги, и тоже могут ошибаться.
И как, я сказал уже, для меня сама информация и знания являются более значимыми, чем их источники.

-----------------------------------------------

Есть еще одна гипотеза. Не смотря на Манифесты, Дейта и т.п., сущетсвуют такие "источники", которые я "читал", а вы - нет.

Ответить | Правка | Наверх | Cообщить модератору

323. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от Kibab (ok), 09-Апр-11, 17:14 
Отвратительная чушь, не имеющая ничего общего с реальностью. Использование NoSQL-решений не способно полностью заменить реляционные СУБД. Везде, где требуются сложные выборки и транзакционность, очень трудно запихать нереляционные базы (см. CAP-теорему и кучу источников по сети)
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

324. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 09-Апр-11, 17:49 
> Отвратительная чушь, не имеющая ничего общего с реальностью. Использование NoSQL-решений не способно полностью заменить реляционные СУБД.

Почему это не способно? Если берут и заменяют.
Нельзя заменить SQL в мозгах всех разработчикам, которые доверяют рекламе. Но такой задачи и не стоит - это их проблемы.

Как правило любой движок реляционной СУБД представляет из-себя нереляционную СУБД.
Просто уберите SQL-надстройку и получите эквивалентное решение. А язык запросов может быть любым. Если еще учесть, что, как уже было сказано, что SQL реляционной модели не соответствует.

Кроме того, вы так легко противопоставляете NoSQL и реляционность, видимо потому что вам кажется, что SQL и реляционность - это по-вашему одно и то же.

> Везде, где требуются сложные выборки и транзакционность, очень трудно запихать нереляционные базы

Ну вот еще один "грамотей", который считает транзакции частью реляционной модели. Это неудивительно, если вы путаете SQL и реляционную модель.

> (см. CAP-теорему и кучу источников по сети).

Видимо долго-долго гуглили и наконец нагуглили сами не знамо что, главное, там иногда встречаются некоторые известные термины.

Ну и что по-вашему реляционная модель такое делает для решения проблем CAP, чего нельзя сделать без реляционной модели? Может еще даже лучше можно?

И наоборот, если альтернативы рел.мод. и SQL не оказались "серебряной пули", это никак не означает, что SQL таковой является. Просто те, кто отказался от SQL, уже "серебряные пули" искать перестали. А остальное большинство все-еще на это надеются.

Кучу каких конкретно других источников? Уж назвали бы конкретно, если знаете?
Кучу рекламы коммерческих SQL-систем и полу-коммерческих OpenSource-communities вокруг них?

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

Ответить | Правка | Наверх | Cообщить модератору

325. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 09-Апр-11, 18:05 
> Везде, где требуются сложные выборки и транзакционность, очень трудно запихать нереляционные базы

Про транзакционность см. выше.

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

Кроме того, в большинстве практических случаев только религия может запретить строить сложные выборки с помощью обычного языка программирования, а не поддерживать дополнительный язык запросов. Хотя бы с использованием банальных объектов-запросов в ООП. Если учесть что SQL-инжекции в код добавляют больше проблем, чем решают.

Вы просто путаете "сложность(простоту)" и "(не)понятность/(не)доступность". Как и большинство дилетантов. Об этом тут тоже уже говорилось.

Ответить | Правка | Наверх | Cообщить модератору

326. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от Kibab (ok), 09-Апр-11, 19:10 
> Почему это не способно? Если берут и заменяют.
> Нельзя заменить SQL в мозгах всех разработчикам, которые доверяют рекламе. Но такой
> задачи и не стоит - это их проблемы.
> Как правило любой движок реляционной СУБД представляет из-себя нереляционную СУБД.
> Просто уберите SQL-надстройку и получите эквивалентное решение. А язык запросов может быть
> любым. Если еще учесть, что, как уже было сказано, что SQL
> реляционной модели не соответствует.

Тут соглашусь. Достаточно вспомнить HandlerSocket. ну и, конечно, SQL не означает автоматически реляционность того, к чему он служит инструментом обращения.

> Кроме того, вы так легко противопоставляете NoSQL и реляционность, видимо потому что
> вам кажется, что SQL и реляционность - это по-вашему одно и
> то же.

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

> Ну вот еще один "грамотей", который считает транзакции частью реляционной модели. Это
> неудивительно, если вы путаете SQL и реляционную модель.

Конечно, они не являются частью реляционной модели, более того, известны примеры, когда реляционная база не умеет транзакционность :)) Скорее, тут речь о том, что при использовании реляционных БД от них ждут, что такая база будет обеспечивать строгую целостность хранения данных (Consistency в терминах CAP-теоремы) и отказоустойчивость при потере части реплик (Availability).В этом случае теряется способность работать при потере части узлов вообще (Partition Tolerance).
Однако, в большинстве известных мне случаев NOSQL-решения выбирают там, где хотят добиться бОльшей возможности горизонтального масштабирования системы (Facebook, Twitter, Digg и другие). В этом случае отсутствие Partition Tolerance становится уже критичным, поэтому реляционные БД, удовлетворяющие классическим CA, для этого плохо подходят. Повторюсь, дело не в реляционности, а в ожиданиях. "так исторически сложилось".
Наличие нереляционных БД наподобие Cassandra, реализующих гораздо более сложную модель данных, чем Key-Value, как бы намекает на возможность создания и реляционной БД со схожими характеристиками.

> Видимо долго-долго гуглили и наконец нагуглили сами не знамо что, главное, там
> иногда встречаются некоторые известные термины.

Да, долго гуглил и читал, я пишу кандидатскую работу по использованию нереляционных БД.
Из интересных ссылок могу привести:
http://blog.nahurst.com/visual-guide-to-nosql-systems#!/slid... -- красивая диаграммка с наглядным представлениям, кто есть где;
http://www.quora.com/How-would-you-compare-and-contrast-MySQ... -- хорошая статья про Partition Tolerance, золотые слова оттуда:
"In either case, auto-sharding is a killer feature of Cassandra, MongoDB, RIak, and most of the NoSQL solutions and tends to be one of _the_ reasons to use these systems over traditional RDBMS systems like MySQL".

> Ну и что по-вашему реляционная модель такое делает для решения проблем CAP,
> чего нельзя сделать без реляционной модели? Может еще даже лучше можно?

см.выше. Так исторически сложилось, что люди ждут от RDMBS букавок CA. Теоретически можно сделать CP. Не знаю примеров. Избавляясь от реляционности, людям всё равно приходится осваивать совершенно новый инструмент, что позволяет им ознакомиться с тем, что реализует AP, без воплей "куда просрали полимеры^W транзакции?!".

http://ria101.wordpress.com/2010/05/12/locking-and-transacti.../ -- транзакции и Cassandra с помощью внешних инструментов. Интересно, в принципе, но сам не пробовал, дурацкий ZooKeeper имеет ограничения на работу под FreeBSD в качестве сервера, а ставить Linux было впадлу;

> И наоборот, если альтернативы рел.мод. и SQL не оказались "серебряной пули", это
> никак не означает, что SQL таковой является. Просто те, кто отказался
> от SQL, уже "серебряные пули" искать перестали. А остальное большинство все-еще
> на это надеются.

Конечно.

> Кучу каких конкретно других источников? Уж назвали бы конкретно, если знаете?
> Кучу рекламы коммерческих SQL-систем и полу-коммерческих OpenSource-communities вокруг
> них?

См.выше. В моих ссылках, кстати, нет реклами ни одного платного проекта.

> Конечно, настрогали столько SQL-разработчиков во время SQL-бума, которые продолжают обучать
> себе подобных. Это давно известно, что общественное массовое сознание обладает большой
> инерцией, так что SQL еще будут какое-то время рекламировать. Столько ведь
> инвестиций в это вбухали.

Угу.

Напоследок приношу извинения за несколько резкий тон моего первого высказывания.

Ответить | Правка | К родителю #324 | Наверх | Cообщить модератору

327. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от diff (??), 09-Апр-11, 20:13 
> Напоследок приношу извинения за несколько резкий тон моего первого высказывания.

Взаимно. Хотя меня мало волновала именно резкость. Меня все-таки больше интересует смысл.

Будем считать, что вы позволили себе некоторую смысловую небрежность, в результате чего, я ошибочно принял вас за "одного из...".

> См.выше. В моих ссылках, кстати, нет рекламы ни одного платного проекта.

В вашем случае это скорее всего действительно так.

Это все относилось к тем, за которых я вас ошибочно принял. К тем, что дальше SQL с проблематикой баз данных особо не знаком.

Насчет "платных проектов" - ту не все так прямолинейно зависит от "платности". В SQL, как межкорпоративный стандарт было вбухано куча инвестиций еще до того, как произошло становление "бесплатных" сообществ. А когда опомнились - весь этот гигантский маховик, включая системы образования и разные сообщества - все это было уже раскручено. И еще долго будут крутиться.

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

-------------------

В остальном я в принципе с вами тоже согласен, кроме двух пунктов.

1. NoSQL (как выяснилось это вообще расщифровывается "Not Only SQL"). Если чего-то нету, это обычно вообще не упоминается. А если люди постоянно сравнивают технологии с SQL, то значит в их сознании доминирует SQL. А не сам _смысл_ и _суть_ баз данных.

А - NoSQL это продолжение извлечения прибыли из ранее сделанных инвестиций в SQL под якобы некоммерческим прикрытием. Ну нет такого языка или технологии NoSQL.

2. Вся эта полемика началась с моего поста, где я высказался о тупике, в который зашла реляционная модель.
Естественно, что все, кто тут же кинулся сразу в "священный бой" против этой "крамолы", даже не утрудились задуматься, а в чем бы мог быть этот самый "тупик".

И стали отстаивать свой любимый SQL, не понимая даже, что SQL - это даже не реляционная система. А также, что все движки SQL систем почему-то тоже нереляционные.

И по сути нормальных практичных реализаций реляционной модели так за всю историю и не сделали. Есть кое-какие академические разработки, в том числе сам Дейт кое что наваял. Но все это почему как раз и не имеет практического применения, на которое все так напирают, отстаивая SQL.

Так в чем проблема реляционной модели?

Для понимания этого вопроса нужно хорошо знать математику. Которую большинство выступающих тут "грамотеев" считают ненужной теорией. А потом из-за таких у нас спутники падают при запуске.

Ответить | Правка | Наверх | Cообщить модератору

40. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от to_php_or_not_to_php (?), 04-Апр-11, 16:29 
> 99% (кроме громадин типа facebook/vk/yahoo/etc) сайтов упираются в работу с SQL, но никак не в производительность PHP.
>

Это у вас какие-то идеальные сайты, написанные идеальными программистами. А у 90% моих PHP-программистов всё ровно наоборот: PHP сжирает все ресурсы, а SQL толком и не используется (так, простейшие селекты, просто в большом количестве, для достаточно быстрой работы которых надо лишь, чтобы база в оперативную память помещалась).

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

158. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +2 +/
Сообщение от php (?), 05-Апр-11, 05:44 
> PHP сжирает все ресурсы

Посоветуйте им хороший профайлер и учебник по программированию для младших курсов.

Ответить | Правка | Наверх | Cообщить модератору

131. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –1 +/
Сообщение от User294 (ok), 04-Апр-11, 21:10 
> 99% (кроме громадин типа facebook/vk/yahoo/etc) сайтов упираются в работу с SQL,

Юзайте базы типа key-value. Геморройнее, но там тормозить особо нечему зато в самой бд. Вы сами себе составляете "план выполнения запроса" и отлично видите насколько много или мало действий надо сделать для достижения результата. Скуль позволяет задвигать умопомрачительные конструкции, при том львиная доля тех кто его юзает ни в зуб ногой не понимает что будет сделано. В результате - резонно появляются "безобидные" запросы лопатящие на ровном месте полбазы и заявы про то что скуль тормозит :). Ну дык кто угодно тормозить будет если полбазы надо прочитать, только скуль позволяет это сделать легко и просто...

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

155. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –1 +/
Сообщение от SkyRangeremail (ok), 05-Апр-11, 02:21 
> Скуль позволяет задвигать умопомрачительные конструкции, при том львиная доля тех кто
> его юзает ни в зуб ногой не понимает что будет сделано.
> В результате - резонно появляются "безобидные" запросы лопатящие на ровном месте
> полбазы и заявы про то что скуль тормозит :). Ну дык
> кто угодно тормозить будет если полбазы надо прочитать, только скуль позволяет
> это сделать легко и просто...

Вообще очень часто тормоза возникают из-за банального отсутствия индексов. После задания индексов производительность как правило резко повышается :) Плюс ко всему часто сталкиваюсь с "select *" вместо "select id, name", например, что тоже дает большие тормоза, если столбцов много. Часто не ставят "limit 1", если надо выбрать запись по ID и так далее.  

На собственном опыте убедился, что 90% проблем возникают из-за ошибок при проектировании структуры БД и неумения найти баланс между четким следованием теории (3-нормальная форма БД и выше) и практической реализации. Если слишком увлечься с нормализацией получатся многоэтажные селекты из кучи с join-ми с которыми может возникнуть куча проблем и найти ошибку может оказаться не так уж и просто.

В общем все познается на личном опыте, другое дело, что большинство не делает из этого выводов.

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

Ответить | Правка | Наверх | Cообщить модератору

177. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  –1 +/
Сообщение от User294 (ok), 05-Апр-11, 11:57 
> Вообще очень часто тормоза возникают из-за банального отсутствия индексов.

По моим наблюдениям, скульщики грешат тем что фигарят запросы нисколько не грея мозг вопросом что же будет по факту сделано. Иногда это оказывается полный педалинг всей немелкой БД.

> часто сталкиваюсь с "select *" вместо "select id, name

Кэп, перелогиньтесь :)

> На собственном опыте убедился, что 90% проблем возникают из-за ошибок
> при проектировании структуры БД и неумения найти баланс между четким
> следованием теории (3-нормальная форма БД и выше) и практической реализации.

Глядя на большую часть запросов есть ощущение что было написано то что первым пришло в голову. А теория и здравый смысл - дружно отдыхали. В какихнить key-value так попросту не получится, поэтому притормозить их говнокодом придется крепко постараться. Это можно, но стараться придется больше :). А то вон на sql.ru был шедевральный пример базы - всего 126 столбцов. Мускул ругался что размер столбца слишком большой и не хотел это создавать :))).Оказывается, птичкодятлы хранили в отдельном столбце ВСЕ, вплоть до цвета шрифта оформления страницы. В общем дурак с бульдозером - еще хуже чем дурак с лопатой.

> а когда станут заметны придется заниматься оптимизацией.

Ну дык, типичная логика скульщика:
- да ладно, и так сойдет: 1.5 юзеров в час на сайте...
- ой! хабра/слэшдот/чтотамеще-эффект. Server down.

Ответить | Правка | Наверх | Cообщить модератору

258. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 06-Апр-11, 16:30 
> Глядя на большую часть запросов есть ощущение что было написано то что
> первым пришло в голову. А теория и здравый смысл — дружно
> отдыхали.

поскольку тут обсуждаем уеб и похапэ, то какая, нафиг, теория? основной массе похапистов сначала бы программировать научиться хотя бы на уровне среднеодарённого школьника. а если их заставить ещё теорию бд изучать и думать, во что их запросы выльются, то поголовье похапистов сильно поредеет, а контингент психушек сильно увеличится.

Ответить | Правка | Наверх | Cообщить модератору

275. "PHP-транслятор HipHop позволил Facebook использовать в разы ..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 09:15 
>> 99% (кроме громадин типа facebook/vk/yahoo/etc) сайтов упираются в работу с SQL,
> Юзайте базы типа key-value. Геморройнее, но там тормозить особо нечему зато в
> самой бд. Вы сами себе составляете "план выполнения запроса" и отлично
> видите насколько много или мало действий надо сделать для достижения результата.

Посоветуйте мне, как упаковать промышленный биллинг в базу типа kv. Желательно с примерами кода, а то я как-то теряюсь.

Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

292. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 07-Апр-11, 11:57 
> Посоветуйте мне, как упаковать промышленный биллинг в базу типа kv. Желательно с
> примерами кода, а то я как-то теряюсь.

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

ах, да, забыл. к «онанимным икспертам» принято относиться с презрением. если ты тоже такой — на здоровье. я лично анонимус по причинам идеологическим (да и какой там анонимус, если IP записывают, и почту записывают?)

Ответить | Правка | Наверх | Cообщить модератору

293. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от AlexAT (ok), 07-Апр-11, 11:58 
> какова оплата за консультацию? там выше ты предлагал тебе заплатить за то,
> чтобы ты переписал свою же систему (от этого платящему только убытки),
> а тут хочешь, чтобы на тебя бесплатно поработали. озвучь сумму, которую
> ты готов потратить на консультантов. если она нам покажется стоящей для
> начала переговоров — возможно, мы с тобой свяжемся.

А зачем мне твоя консультация? У меня и без NoSQL все прекрасно работает, и все эти бредни про "SQL-зло" так бреднями и останутся.

ПыСы. Без NoSQL на основной базе. На кешах сидит memcached.

Ответить | Правка | Наверх | Cообщить модератору

296. "PHP-транслятор HipHop позволил Facebook использовать в..."  +/
Сообщение от anonymous (??), 07-Апр-11, 12:05 
> А зачем мне твоя консультация? У меня и без NoSQL все прекрасно
> работает

да незачем, конечно. просто когда подошвы припекает — консультанты больше денег берут.

> и все эти бредни про «SQL-зло» так бреднями и останутся.

конечно. потому что ты их сам выдумал, и с ними сражаешься. я не знаю, где diff (и я, как примазавшийся) говорили, что «SQL-зло». всего лишь: «SQL — не silver bullet; не надо его пихать во все дырки, особенно в невпихуeмые».

> ПыСы. Без NoSQL на основной базе. На кешах сидит memcached.

тоже решение. возможно, даже оптимальное по сумме критериев. не видел системы, не знаю. но на основе неполных данных, которые ты выдал, сомневаюсь в необходимости в системе SQL-прослойки вообще.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру