Все зависит от задачи. Могу только сказать по hadoop/hbase, с которым приходится работать: да, join'ы делаются на уровне приложения (там по сути используется технология Map-Reduce, поищите в гугле например книжку «Hadoop: The Definitive Guide» — там отдельная глава joinэам посвящена).
Про память: в память большие объемы в принципе загрузить нереально, а на небольших — почему бы и нет, опять же от задачи зависит.
Про скорость. Как Вы догадались, зависит от задачи ;) Кластер с hadoop/hbase миллиарды записей обработает на десятки секунд, а тот же mysql просто помрет или будет неделю считать. Здесь скорость явно за nosql. С другой стороны, запрос к hbase на несколько тысяч записей только инициализироваться будет секунды, пока вся эта махина поднимется и начнет данные пережевывать, в то время как mysql отработает за миллисекунды. Скорость разработки на порядок выше в SQL — потому что всю низкоуровневую работу берет на себя сервер БД и на уровне приложения делать ничего не надо.
Вобщем, как всегда, надо начинать с постановки задачи и выбирать инструмент под нее.
Сделать можно, но не всегда это тривиально.
Если тот же mysql преобразует все запросы в сложные выборки внутри базы и наружу торчит только SQL-запрос, то в случае например hbase — трудитесь сами. Для того же hbase есть надстройка в виде Pig — помогает немного упростить жизнь, но сделать ее такой же халявной, как в чистом SQL — фигвам. Опять же, в nosql отсутсвуют множественные индексы (по ключу индекс есть), ибо их обновлять при миллирадном числе записей просто нереально — отсюда вытекает часто чистый перебор данных.
Вы сами задали вопрос и сами же на него ответили: для маленьких магазинов все вполне укладывается в обычные реляционные базы.
Насчет масштабирование в тысячи раз исходя из Ваших данных «не более 300 позиций» мы получим 300 * 1000 = 300000. Ну добавим еще пару нулей. Миллионы. Сомневаюсь, что это так просто отмасштабируется, хотя вполне реально наверно, если сильно помучаться — не пробовал. Я же говорю о миллиардах. Вцелом я не хочу Вас ни в чем убеждать, области применения nosq баз не раз описывались на том же хабре, гугл хранит в nosql базе свои базы для поисковика ну и т.д.
Да и мы стали применять nosql тогда, когда реляционные базы оказались неспособны работать с большими объемами.
Меня вот как-то прям коробит от Вашего тона и игру в экзаменатора… ну да ладно.
А по сути статья об очевидном: что удобней, то и надо использовать. Есть и плюсы, и минусы у каждого подхода.
Да, маленький магазин проще писать с mysql например. А миллиардные хранилища — на Nosql каком-нибудь.
В проекте, над которым я работаю — там используется четыре языка программирования, естественно разные библиотеки, ну и конечно же разные базы данных для разных целей: postgres, mtsql, hbase. И кэширование тоже используется.
А в маленьком проекте конечно тянуть такой зоопарк нереально — просто человеческих ресурсов не хватит.
Так что каждому — свое.
Просто раньше линуксы не выходили пачками, не надо было с выходом каждого апдейта учить кучу новых команд и забывать старых, не надо было фиксить кучу новых багов. А тут вот как описано — на форумах поминаются команды — а их уже давно след простыл.
А ведь хочется жизнь тратить на что-то полезное кроме изучения новых багов и настройки дистрибов.
Сие уже поправили, даже работает. Но да, пичалька наблюдалась в самый неподходящий момент.
И все потому, что куда-то бежим, куда-то торопимся, в результате отстаем. Вот так-то.
Пора походу остановиться и немного подумать, что делает убунта и зачем и надо ли оно вообще.
> и считает, что теперь все сайты должны эффективно использовать это пространство
А Вы считаете, что пространстро надо использовать неэффективно?
Может все-таки сайты должны удовлетворять требованиям пользователей, или нет?
Я еще понимаю, на всякие непонятные хотелки обращать внимания не стоит, но оставлять пол монитора пустым — это что, нормально?!
К ленте.ру те же претензии, но там хоть не пол монитора, а одна треть всего.
Итого, для получения кармы теперь, у кого ее мало, могут только написать крутой комментарий.
Ибо написать статью — нельзя, т.к. кармы мало, задать вопрос или ответить на него — нельзя, ибо вопросы ушли.
А с учетом того, что комментарии очень слабо влияют на карму — карму изменить нелья, т.е. много, кто мог бы что-то писать — уже никогда до этого не дорастет.
Ну что ж, посмотрим, кому от этого будет хорошо.
По сути, если ушли одни механизмы регулирования — дайте взамен другие! Иначе ресурсу станет плоховасто.
Не, на хабре все же удобней было — пропорциональное заполнение, чисто визуально вполне адекватно смотрится. А так половина пустая, половина заполнена, очень како-то кособоко. Кнопочки и т.п. может и удобно, но вот как заходишь — и сразу кособокостью прям по морде — очень грустно.
Про память: в память большие объемы в принципе загрузить нереально, а на небольших — почему бы и нет, опять же от задачи зависит.
Про скорость. Как Вы догадались, зависит от задачи ;) Кластер с hadoop/hbase миллиарды записей обработает на десятки секунд, а тот же mysql просто помрет или будет неделю считать. Здесь скорость явно за nosql. С другой стороны, запрос к hbase на несколько тысяч записей только инициализироваться будет секунды, пока вся эта махина поднимется и начнет данные пережевывать, в то время как mysql отработает за миллисекунды. Скорость разработки на порядок выше в SQL — потому что всю низкоуровневую работу берет на себя сервер БД и на уровне приложения делать ничего не надо.
Вобщем, как всегда, надо начинать с постановки задачи и выбирать инструмент под нее.
Если тот же mysql преобразует все запросы в сложные выборки внутри базы и наружу торчит только SQL-запрос, то в случае например hbase — трудитесь сами. Для того же hbase есть надстройка в виде Pig — помогает немного упростить жизнь, но сделать ее такой же халявной, как в чистом SQL — фигвам. Опять же, в nosql отсутсвуют множественные индексы (по ключу индекс есть), ибо их обновлять при миллирадном числе записей просто нереально — отсюда вытекает часто чистый перебор данных.
Насчет масштабирование в тысячи раз исходя из Ваших данных «не более 300 позиций» мы получим 300 * 1000 = 300000. Ну добавим еще пару нулей. Миллионы. Сомневаюсь, что это так просто отмасштабируется, хотя вполне реально наверно, если сильно помучаться — не пробовал. Я же говорю о миллиардах. Вцелом я не хочу Вас ни в чем убеждать, области применения nosq баз не раз описывались на том же хабре, гугл хранит в nosql базе свои базы для поисковика ну и т.д.
Да и мы стали применять nosql тогда, когда реляционные базы оказались неспособны работать с большими объемами.
А по сути статья об очевидном: что удобней, то и надо использовать. Есть и плюсы, и минусы у каждого подхода.
Да, маленький магазин проще писать с mysql например. А миллиардные хранилища — на Nosql каком-нибудь.
В проекте, над которым я работаю — там используется четыре языка программирования, естественно разные библиотеки, ну и конечно же разные базы данных для разных целей: postgres, mtsql, hbase. И кэширование тоже используется.
А в маленьком проекте конечно тянуть такой зоопарк нереально — просто человеческих ресурсов не хватит.
Так что каждому — свое.
Не вся публика каждый день стили настраивает ;)
и тогда вопрос — зачем такая редакция? ;)
мне кажется, что раз уж есть готовый более адекватный стиль — так его надо применить на самом тостере, а не извращаться всем и каждому…
А ведь хочется жизнь тратить на что-то полезное кроме изучения новых багов и настройки дистрибов.
И все потому, что куда-то бежим, куда-то торопимся, в результате отстаем. Вот так-то.
Пора походу остановиться и немного подумать, что делает убунта и зачем и надо ли оно вообще.
А Вы считаете, что пространстро надо использовать неэффективно?
Может все-таки сайты должны удовлетворять требованиям пользователей, или нет?
Я еще понимаю, на всякие непонятные хотелки обращать внимания не стоит, но оставлять пол монитора пустым — это что, нормально?!
К ленте.ру те же претензии, но там хоть не пол монитора, а одна треть всего.
Ибо написать статью — нельзя, т.к. кармы мало, задать вопрос или ответить на него — нельзя, ибо вопросы ушли.
А с учетом того, что комментарии очень слабо влияют на карму — карму изменить нелья, т.е. много, кто мог бы что-то писать — уже никогда до этого не дорастет.
Ну что ж, посмотрим, кому от этого будет хорошо.
По сути, если ушли одни механизмы регулирования — дайте взамен другие! Иначе ресурсу станет плоховасто.
Линуксовый Андроид ставится с помощью винды, а на линуксе инсталлятора нет.
Абсурдненько, да…
Хм… кажется справа стало столько лишнего простаранства, что стало только хуже.
Так что на цель, которая достигнута — это мало похоже.