Чтоб держать пару конфигов в версионном виде и ради этого поднимать гит — это из пушки по воробьям ИМХО.
Для больших задач — сложные инструменты, для простых — простые.
Для таких целей завсегда существовала тулза под названием "rcs"
rcs creates new RCS files or changes attributes of existing ones. An RCS file contains multiple revisions of text, an access list, a change log, descriptive text, and some control attributes.
Кстати, если попадание в тостер было из хабры и усер является хабраусером, то либо клик на нике дожен вести к хабра-инфе, либо инфа должна отражать его присутствие в в том числе и на хабре и включать в себя его хабрарейтинг и т.п.
Да-да, именно так было бы здорово!
И еще, раз все равно аккаунт хабры общий с тостером, то таким боком неявно вернется хаброплюсование за карму, и табчик «Q&A» вернется на свое законное по смыслу место, ибо оно уже станет связано с хаброй.
Все зависит от задачи. Могу только сказать по 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. И кэширование тоже используется.
А в маленьком проекте конечно тянуть такой зоопарк нереально — просто человеческих ресурсов не хватит.
Так что каждому — свое.
Просто раньше линуксы не выходили пачками, не надо было с выходом каждого апдейта учить кучу новых команд и забывать старых, не надо было фиксить кучу новых багов. А тут вот как описано — на форумах поминаются команды — а их уже давно след простыл.
А ведь хочется жизнь тратить на что-то полезное кроме изучения новых багов и настройки дистрибов.
Сие уже поправили, даже работает. Но да, пичалька наблюдалась в самый неподходящий момент.
И все потому, что куда-то бежим, куда-то торопимся, в результате отстаем. Вот так-то.
Пора походу остановиться и немного подумать, что делает убунта и зачем и надо ли оно вообще.
Для больших задач — сложные инструменты, для простых — простые.
И еще, раз все равно аккаунт хабры общий с тостером, то таким боком неявно вернется хаброплюсование за карму, и табчик «Q&A» вернется на свое законное по смыслу место, ибо оно уже станет связано с хаброй.
Про память: в память большие объемы в принципе загрузить нереально, а на небольших — почему бы и нет, опять же от задачи зависит.
Про скорость. Как Вы догадались, зависит от задачи ;) Кластер с 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. И кэширование тоже используется.
А в маленьком проекте конечно тянуть такой зоопарк нереально — просто человеческих ресурсов не хватит.
Так что каждому — свое.
Не вся публика каждый день стили настраивает ;)
и тогда вопрос — зачем такая редакция? ;)
мне кажется, что раз уж есть готовый более адекватный стиль — так его надо применить на самом тостере, а не извращаться всем и каждому…
А ведь хочется жизнь тратить на что-то полезное кроме изучения новых багов и настройки дистрибов.
И все потому, что куда-то бежим, куда-то торопимся, в результате отстаем. Вот так-то.
Пора походу остановиться и немного подумать, что делает убунта и зачем и надо ли оно вообще.