Разработчики одного из крупнейших сетевых ресурсов Digg.com приняли решение (http://about.digg.com/node/564) отказаться от использования СУБД MySQL в пользу распределенной БД Apache Cassandra (http://incubator.apache.org/cassandra/), исходные тексты которой были открыты компанией Facebook два года назад. Работа по миграции Digg на уход от использования SQL заняла шесть месяцев, за которые не просто были переписаны все обеспечивающие работу сайта приложения, но и была полностью переработана архитектура клиентской и серверной части проекта.
Главные мотивы ухода от использования MySQL: усложнение решений, при необходимости обеспечения высокой производительности и проблемы при интенсивной записи данных. Рост нагрузки заставлял разработчиков пересматривать стратегию горизонтального и вертикального партицирования (сегментирование записей по хранилищам в соответствии с определенным алгоритмом привязки к диапазону хранимых значений), при этом использование реляционной схемы приводило к бол...URL: http://about.digg.com/node/564
Новость: http://www.opennet.me/opennews/art.shtml?num=25758
Ну любой отход от SQL можно только приветствовать. БД на Java, правда, вызывает некое недоумение.
Почему?
Видимо это как-то связано с тем, что java очень сильно нагружает процессор и жрёт оперативку.
> Видимо это как-то связано с тем, что java очень сильно нагружает процессор
> и жрёт оперативку.Ага. А SQL процессор не нагружает и оперативку не жрёт. :)
Ну дык сиквель и логику запросов какую педалит? Ессно при этом он не может не жрать. Чудес не бывает - запросы или уж навороченны, или быстрые.
> Видимо это как-то связано с тем, что java очень сильно нагружает процессор и жрёт оперативку.Пока одни кормятся мифами, другие извлекают профиты.
Увы да. Многие считают, что у java оверхеда нет или он находится на приемлимом уровне, а другие тем временем ставят в 4 раза меньше серверов для тех же задач.
>Увы да. Многие считают, что у java оверхеда нет или он находится
>на приемлимом уровне, а другие тем временем ставят в 4 раза
>меньше серверов для тех же задач.Пусть ставят. Если есть готовый софт, то отлично ;)
Отличие только в скорости разработки. Потому чем сложнее софт, тем больше стремление применить для него языки высокого уровня Java/C#. Результат получается раньше и требует меньше программистов для реализации.
Это огромная экономия средств окупающая и дополнительные сервера и оперативку. Самое дорогое в создании софта это люди, а не сервера или лицензии. Плюс выход на рынок 2-3 месяца раньше чем конкуренты это просто пипец как много.
PS + коммерческого OpenSource больше всего на java - тот же Apache это почти все java-проекты.
Вот вот, знаем мы этот ынтерпрайзный тяп-ляп подход. Больше добавить нечего.
>Вот вот, знаем мы этот ынтерпрайзный тяп-ляп подход. Больше добавить нечего.Сделайте лучше ;) никто не мешает сделать аналог Hadoop или HBase или Cassandra на С/С++ или любом другом "правильном" языке.
Hadoop это OpenSource аналог гугловского Map-Reduce, HBase это OpenSource аналог гугловского BigTable.
Только никто в это реально вкладываться не будет. А такие как я Java разработчики и дальше будут клепать софт для больших контор применяя JavaSE или JavaEE в зависимости от того, на чем проще сделать.
PS как вы думаете на каком софте работают фармацевтические исследовательские лаборатории?
>>PS как вы думаете на каком софте работают фармацевтические исследовательские лаборатории?СУБД Cache...
>СУБД Cache...Ну точно не эта. Oracle или PostgreSQL (для маленьких лаб.)
Скажите это, например, Google.
Чего-то я не замечал, чтобы тормозил Gmail, поисковик и т.д.
С такими-то кластерами кшна не будет. Подумаешь, по машине на клиента. Тут пробегало как-то сколько CO2 выделяется от одного поискового запроса. Гуглу-то похрен, они могут и обезьян со счетами нанять mapreduce им считать. А вот в более преземленных компаниях принято считать деньги. И жавамоны если и использовать, то только для того, на что они годятся - прототипирование. В долгосрочной перспективе от них избавляются.
>С такими-то кластерами кшна не будет. Подумаешь, по машине на клиента. Тут
>пробегало как-то сколько CO2 выделяется от одного поискового запроса. Гуглу-то похрен,А в чем проблема то от СО2? Или вы верите в глобальное техногенное потепление? нефиг вырубать экваториальные леса и свякую хрень в моря сливать, тогда проблем от СО2 будет ноль.
>Чего-то я не замечал, чтобы тормозил Gmail, поисковик и т.д.А вы поставьте столько же серверов - у вас тоже ничего тормозить не будет :)
Не в серверах дело, а в масштабируемости.
Здесь довольно подробно рассмотрен вопрос производительности JVM, включая случаи, когда выгоднее использовать C, случаи когда Java эффективнее и спорные случаи:
http://blogs.azulsystems.com/cliff/2009/09/java-vs-c-perform...
Ага. Или на ассемблере все переписывают и вообще обходятся нетбуком...Есть еще понятия скорость разработки и много других интересных показателей.
Вот как Go в продакшн можно будет использовать - тады другой будет разговор.Но ведь и там жрущее ресурсы GC. Оно не зря придумано. Оно реально повышает стабильность серверных приложений и позволяет избегать очень трудоемкой отладки.
java выполняется в виртуальной машине, что несколько снижает производительность по сравнению с нативным кодом.
>java выполняется в виртуальной машине, что несколько снижает производительность по сравнению с
>нативным кодом.практически это может оказаться заблуждением ибо JIT. с JIT может сравниться только gentoo пересобранная под конкретную машину.
плюс автоматическое управление памятью может быть намного быстрее ручного.
Правильно, товарищ ! :-)Тормозить может сборщик мусора, если настроить неправильно.
Есть места, где производительность критична, а есть совершенно некритичные к производительности.
В большинстве случаев в критичных местах выполняется машинный код, который оптимизирован под данный процессор JIT-ом.
> Тормозить может сборщик мусора, если настроить неправильноа как правильно настроить? По-моему, это очередной миф - все об этом говорят, но никто толком правильно настроенный и не видел.
Как показала жизнь, правильно писать код на java удается совсем не многим, и N+1 gc по прежнему плохо справляется с мусором с любыми настройками.
> Как показала жизнь, правильно писать код на java удается совсем не многим,
> и N+1 gc по прежнему плохо справляется с мусором с любыми
> настройками.Как показала жизнь - Cassandra реально живет и обслуживает один из самых нагруженных сайтов в мире.
>практически это может оказаться заблуждением ибо JIT. с JIT может сравниться только gentoo пересобранная под конкретную машину.Практически-тестово гораздо хуже
http://www.mobydisk.com/softdev/techinfo/speedtest/index.html
It looks like JIT comes in at about half the speed of a purely compiled language.
а практически-практически все еще хуже. Сравните оффис без дотнета и новый с дотноетом. Или автокад.
> java выполняется в виртуальной машине, что несколько снижает производительность по сравнению
> с нативным кодом.Сударь теоретиг? Плохой теоретиг: не знает, что JIT существует уже очень много лет как.
Вам известно такое понятие, как "компромисс" ?Один из примеров: сервер купить проще, чем нанять лишних людей и увеличить сроки внедрения.
>Вам известно такое понятие, как "компромисс" ?
>
>Один из примеров: сервер купить проще, чем нанять лишних людей и увеличить
>сроки внедрения.Вот именно!
И самое интересное, что люди, пытающиеся заменить сервер, будут выделять на фиг знает сколько порядков больше CO2, чем сервер такой же производительности.
Известно. Поэтому вместо 10 серверов под жаву я куплю 2 под C/C++. Разумеется, если нужная мне функциональность реализована на C++. Тут у java преимущество в скорости разработки, но это только подтверждает мой тезис - java/mono годны только для прототипирования.
> Известно. Поэтому вместо 10 серверов под жаву я куплю 2 под C/C++.
> Разумеется, если нужная мне функциональность реализована на C++. Тут у java
> преимущество в скорости разработки, но это только подтверждает мой тезис -
> java/mono годны только для прототипирования.В современной жизни - скорость разработки это важно.
Сколько там миллиардов у Цукерберга (создатель FaceBook). А ведь идея то в воздухе носилась. Он просто первый успел.
"Java" и "хорошо работает" в одном предложении встречаются редко (Кто-то из lxf упомянул этими словами Apache Ant). Ля скептре, но по-моему реляционные БД клайстеризуются и позволяют программировать внутри себя. Да и ресурсы по сравнению с монстром по имени жаба - все равно, что Камаз 5320 с Дафом FX равнять. Да представляю - российские перевозчики содятся на Камазы: "Москва умрет с голоды за 2 месяца". Но это лирика...
>"Java" и "хорошо работает" в одном предложении встречаются редко (Кто-то из
>lxf упомянул этими словами Apache Ant). Ля скептре, но по-моему реляционные
>БД клайстеризуются и позволяют программировать внутри себя. Да и ресурсы по
>сравнению с монстром по имени жаба - все равно, что Камаз
>5320 с Дафом FX равнять. Да представляю - российские перевозчики содятся
>на Камазы: "Москва умрет с голоды за 2 месяца". Но это
>лирика...Мало вы софта видели ;) я даже VoIP сервер видел полностью на java, причем это было лет 5 назад сделано )))
А реляционные СУБД практически не кластеризуются. Причем кластера стоят бешенных денег, намного больших чем просто набор (сервера + СУБД) в количестве нод.
Oracle RAC имеет 4 ноды, больше то ли не тянет, то ли не рекомендуется ибо скорость падает. Плюс ему нужно внешнее хранилище ибо работает через shared data. Плюс ему еще и сертифицированные ОС требуются. В итоге куча бабла =) Для больших инет проектов цена лицензий тоже не последняя вещь.
Кассандра вещь бесплатная плюс она ОЧЕНЬ быстрая на запись, а РСУБД кластерами как раз на запись то медленные.
> "Java" и "хорошо работает" в одном предложении встречаются редко (Кто-то из
> lxf упомянул этими словами Apache Ant). Ля скептре, но по-моему реляционные
> БД клайстеризуются и позволяют программировать внутри себя. Да и ресурсы по
> сравнению с монстром по имени жаба - все равно, что Камаз
> 5320 с Дафом FX равнять. Да представляю - российские перевозчики содятся
> на Камазы: "Москва умрет с голоды за 2 месяца". Но это
> лирика...Cassandra работает. На самом деле работает....
ну мы хадупом шас балуемся. Пока перспективы видны. Посмотрим до чего доекспереиентируемся