инфраструктурное, базы
на самом деле все эти nosql - это чисто persistent надстройка над мемкешем. над простым key-value. нет, оно хорошо и местами нужно, но в плане предыдущепостового "а как бы сделать простенький дефолт sql" хочется сказать следущее:
в вебе не хватает вот этого key-value, но и full-sql нафик не нужон, вот в таком, текущем виде. не, я видел развесистые запросы и тут, но а) до сурового несерверного тут далеко все еще б) все равно такие развесистые не нужны. а среднего решения сейчас - нету.
кто-то может канеш привести пример из nosql, но нет. тупо нет.
критеризация тут простая и дубовая
- если нет джойнов это ваще не sql, лучше даже не писать это слово в описании\названии\где еще
- джойны - нужны. но в простом виде, аля full + left. все эти right\outer и прочее - в помойку
- это означает, что можно и нужно сильно упрощать синтаксис, в пользу быстрого разбора запроса в первую очередь. возможно, даже шоп его можно было стандартно упихивать в жесткую структуру аля предкомпайл
- это же означает, что вот этим все джойны, шоп не гонять данные, надо уметь прям на сервере или где там - временно сохранять (!!) и управлять (!!)
- не, я могу ща вроде сказать select * вот сюда, а потом совсем отдельно "а теперь пройдись мне вот этому собранному", но как только слышится "временные таблицы", почему-то всплывает "просадки производительности". казалось бы...
- то есть, для современного веба, а возможно и современной обработки данных аля не "бухгалтерия микрософт за пицот лет", а более time-oriented, massive, многопотоковых, те типа отдельных юзеров - вообще имеет смысл упрощать sql с одной стороны, параллелизовать обработку, а с другой стороны - выпучиться в сторону хранения промежуточных результатов и их управлением. вот где и пригодятся новые многоядерные процы, если еще и будут отдельные многоядерные (тм) системы хранения.
- mapreducе это тоже не то. ну, как минимум не совсем то. к примеру, выгрести топ юзеров по критерию оно еще подходит, а вот выгрести список френдов с данными для конкретного с разных серверов - уже куку. а это чисто джойн! причем, очевидно, что первый шаг "взять списочег id" не параллелится, а второй "выгрести данные по юзерам с их id с разных тачек" - да!!
- понятно, что сам sql никуда не девается, он нужен, но для других типов задач. (почему, кстати, его же не натянуть ровно на те же данные - отдельный вопрос)
занафига оно? а затем, что количество запросов на страницу все еще роляет. это означает, что вся канителька с доступом в базу тормозная и индустриально не подходит для массовых веб запросов. именно поэтому там юзается как правило кеш. но это же архитектурно странно! я почему-то могу выгрести и быстро сотню закешенных данных по одному и не могу - сотню таких же данных с базы. какой бы быстрой она не была. чувствуется нюанс? (тм) это означает что вот этот оверхед нужно изничтожать.
а уж как только я слышу, что в этом процессе участвует аш оптимизатор запросов (!!), то хочется рыдать, потому, что еще голубей с жесткими дисками там не хватало. это для запросов-то не сложнее select from left join where. ведь если надо - то не проблема и указать что оно read-only и даже ручками указать отдельно select\join\where. лишь бы ну не наворачивали шарики на елку!
зато как тока речь заходит про sharding, реплики, bulk import, и прочее, натурально более нужное чем right join - начинается танец с бубнами и шаманизъм.
именно поэтому нужно ответвление (или как его) sql, которое выпячивается вот именно сюда. в большие наборы примерно одинаковых данных, характерных своей независимостью по частям.
кстати, это уже больше похоже на студенческую штуку! которую можно попробовать и поднять, даже в одно рыло. сначала на одном хосте в рамках "а почему бы не встроить это в похопе, шоп на нем можно было поднять типичный функционал авторизация\бложек с тегами", а потом чуть более распараллелить нахрен напропалую.
ps причем понятно, что full-sql щикам оно нафик, потому, что у них это ключевой момент. nosql key-value щикам такое ощущение, что сложно. а где вот это чуть более сложное? бери sql, выкидывай все, окромя full join+left join+where и фсйо! и если чо, в where сложного встретится - тупо выкидывать также! а для веселухи сразу можно подумать про интересные sharding и прочий highload, неужто неподъемно и неинтересно?
psps
а как насчет такого, к примеру?
select user_id, user_name from users
left join memcache:rating on m.user_id=u.user_id
в вебе не хватает вот этого key-value, но и full-sql нафик не нужон, вот в таком, текущем виде. не, я видел развесистые запросы и тут, но а) до сурового несерверного тут далеко все еще б) все равно такие развесистые не нужны. а среднего решения сейчас - нету.
кто-то может канеш привести пример из nosql, но нет. тупо нет.
критеризация тут простая и дубовая
- если нет джойнов это ваще не sql, лучше даже не писать это слово в описании\названии\где еще
- джойны - нужны. но в простом виде, аля full + left. все эти right\outer и прочее - в помойку
- это означает, что можно и нужно сильно упрощать синтаксис, в пользу быстрого разбора запроса в первую очередь. возможно, даже шоп его можно было стандартно упихивать в жесткую структуру аля предкомпайл
- это же означает, что вот этим все джойны, шоп не гонять данные, надо уметь прям на сервере или где там - временно сохранять (!!) и управлять (!!)
- не, я могу ща вроде сказать select * вот сюда, а потом совсем отдельно "а теперь пройдись мне вот этому собранному", но как только слышится "временные таблицы", почему-то всплывает "просадки производительности". казалось бы...
- то есть, для современного веба, а возможно и современной обработки данных аля не "бухгалтерия микрософт за пицот лет", а более time-oriented, massive, многопотоковых, те типа отдельных юзеров - вообще имеет смысл упрощать sql с одной стороны, параллелизовать обработку, а с другой стороны - выпучиться в сторону хранения промежуточных результатов и их управлением. вот где и пригодятся новые многоядерные процы, если еще и будут отдельные многоядерные (тм) системы хранения.
- mapreducе это тоже не то. ну, как минимум не совсем то. к примеру, выгрести топ юзеров по критерию оно еще подходит, а вот выгрести список френдов с данными для конкретного с разных серверов - уже куку. а это чисто джойн! причем, очевидно, что первый шаг "взять списочег id" не параллелится, а второй "выгрести данные по юзерам с их id с разных тачек" - да!!
- понятно, что сам sql никуда не девается, он нужен, но для других типов задач. (почему, кстати, его же не натянуть ровно на те же данные - отдельный вопрос)
занафига оно? а затем, что количество запросов на страницу все еще роляет. это означает, что вся канителька с доступом в базу тормозная и индустриально не подходит для массовых веб запросов. именно поэтому там юзается как правило кеш. но это же архитектурно странно! я почему-то могу выгрести и быстро сотню закешенных данных по одному и не могу - сотню таких же данных с базы. какой бы быстрой она не была. чувствуется нюанс? (тм) это означает что вот этот оверхед нужно изничтожать.
а уж как только я слышу, что в этом процессе участвует аш оптимизатор запросов (!!), то хочется рыдать, потому, что еще голубей с жесткими дисками там не хватало. это для запросов-то не сложнее select from left join where. ведь если надо - то не проблема и указать что оно read-only и даже ручками указать отдельно select\join\where. лишь бы ну не наворачивали шарики на елку!
зато как тока речь заходит про sharding, реплики, bulk import, и прочее, натурально более нужное чем right join - начинается танец с бубнами и шаманизъм.
именно поэтому нужно ответвление (или как его) sql, которое выпячивается вот именно сюда. в большие наборы примерно одинаковых данных, характерных своей независимостью по частям.
кстати, это уже больше похоже на студенческую штуку! которую можно попробовать и поднять, даже в одно рыло. сначала на одном хосте в рамках "а почему бы не встроить это в похопе, шоп на нем можно было поднять типичный функционал авторизация\бложек с тегами", а потом чуть более распараллелить нахрен напропалую.
ps причем понятно, что full-sql щикам оно нафик, потому, что у них это ключевой момент. nosql key-value щикам такое ощущение, что сложно. а где вот это чуть более сложное? бери sql, выкидывай все, окромя full join+left join+where и фсйо! и если чо, в where сложного встретится - тупо выкидывать также! а для веселухи сразу можно подумать про интересные sharding и прочий highload, неужто неподъемно и неинтересно?
psps
а как насчет такого, к примеру?
select user_id, user_name from users
left join memcache:rating on m.user_id=u.user_id