Клуб hi-Tech-гуру «WEB»

15 января 2012 года, Википедия празднует свой день рождения. Ей исполняется 11 лет. За 11 лет своего существования Википедия подарила миру надёжный источник качественной информации, свободный доступ к которой имеет каждый. Для большинства пользователей, которые пользуются Википедией, множество интересного, полезного и познавательного остаётся за кадром.
Полагаю, что сегодня нам стоит про это поговорить. Кто знает, может кому-то это поможет в поиске информации, а в ком-то раскроет талант автора, и тогда совсем скоро украинский сегмент Википедии станет ещё больше, информативней, интересней.

Читать подробнее...

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

Читать подробнее...

В данной статье речь пойдет о нестандартных и интересных счетчиках сбора статистики посещения веб-страниц

Читать подробнее...

Шопінг в Інтернеті став уже звичайною буденною справою. При пошуку будь-якого товару ми відразу звертаємось до Всесвітньої мережі. А як же бути, якщо ми самі хочемо продати щось? Де розмістити оголошення? Чи варто платити за нього? Про ці та інші питання піде далі мова в даному матеріалі.

Читать подробнее...

С ситуацией когда вдруг захотелось что-то почитать сталкивался наверное каждый. Но одно дело, когда такое желание наступает в процессе прогулки где-нибуть на Петровке, и проблему информационного голода можно быстро решить. Но другой вопрос, когда сидишь вечером дома (в лесу в палатке и т.п.), киоски закрыты, а любимый журнал не завезли. Что делать? Где найти свежий номер журнала. Конечно в Интернет. Я здесь не буду рассказывать о торрент-трекерах где можно скачать море литературы, хотя если речь идет о журналах то, как правило, с уже устаревшей (2-3 месяца) информацией. В статье поговорим о специальных сервисах, на которые издатели помещают свои журналы, а читатели могут вполне легально почитать в любое время и месте, где есть доступ к Интернету.

Читать подробнее...

Час минає, летить невпинно, немов зі швидкістю світла безжально переносить людину в кінець життєвого циклу, підводячи великий підсумок сенсу життя. Неначе екранізована неймовірна історія Бенджаміна Бартона, яка лише за 2,5 години перегляду демонструє глядачу життя головного героя, минає блискавкою. Людство завжди вважало, що відведеного для нього часу замало.

Читать подробнее...

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

Читать подробнее...

e-mail: avreliy@bigmir.net

Давным-давно, в конце прошлого года, автор проводил обзор файлообменников в украинском сегменте сети интернет.

Читать подробнее...

В один прекрасный день вы обнаруживаете, что на сайте увеличился зарубежный трафик. Любой новый посетитель не может не радовать блоггера, но анализ отказов показывает, что все новички быстро уходят. Объясняется все просто - язык. И хотя сегодня возможность автоматического перевода поддерживают браузеры Google Ghrome и Firefox с установленной панелью от Google, надеяться, что именно такой будет браузер у посетителя не стоит.

Читать подробнее...

e-mail: avreliy@bigmir.net

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

Читать подробнее...

e-mail: avreliy@bigmir.net


Вечером в воскресение 23 мая в Германии завершился Чемпионат мира по хоккею-2010.

Завершился триумфом сборной ...

Читать подробнее...

e-mail: avreliy@bigmir.net

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

Читать подробнее...

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

Читать подробнее...

В последнее время коллективные блоги и разного рода социальные сообщества стали довольно популярны и будучи построенными по принципу генерации контента самими пользователями (user-generated content) они стали стремительно развиватся. И вот, 10 сентября 2008 года была выпущена первая версия open-source движка LiveStreet, который был создан российским php-разработчиком Максимом Мжельским. Впервые движок был анонсирован на habrahabr.ru, кстати первоначальный дизайн LiveStreet был позаимствован у этого сайта. Спустя чуть более года, LS сменил дизайн, получил порядочное количество положительных отзывов и продолжает пользоваться популярностью.

Читать подробнее...

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

Читать подробнее...

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

Читать подробнее...

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

Читать подробнее...

Недавно мы поднимали вопрос о создании блогов на базе движка WordPress, однако, блог - это одно, а полноценный сайт, портал и форум - совсем другое.
В данной статье мы рассмотрим популярные CMS (Content management system), как основу для создания полноценного веб-портала.

Читать подробнее...

В первых двух частях обзора (Проблемы масштабируемости современных веб-приложений и Проблемы масштабируемости современных веб-приложений: решение) было расссмотрено, чем на сегодняшний день РБД не устраивают веб-приложения и какую замену им придумали умные люди. В этой завершающей части цикла мы рассмотрим, какие же есть решения на рынке key-value БД.
Начнем с известной Мemcached. Эта key-value БД кэширует данные в оперативной памяти на основе парадигмы распределенной хэш-таблицы.
В API memcached есть только базовые функции: выбор сервера, установка и разрыв соединения, добавление, удаление, обновление и получение объекта. Для каждого объекта устанавливается время жизни, от 1 секунды до бесконечности. При переполнении памяти более старые объекты автоматически удаляются [http://ru.wikipedia.org/wiki/Memcached]. Минусы данного решения следующие: все данных хранятся в памяти, данные могут быть только строкового или численного типа, а также существуют сложности выборки одним запросом множества ключей. Есть дистрибутивы для платформ Windows, Mac OS X, BSD Unix, Linux, Solaris. Сервер memcached был разработан для сайта LiveJournal с целью снижения нагрузки на сервера баз данных. На сегодняшний день проект Facebook.com имеет самую большую в мире инсталляцию серверов memcached.

Следующее решение - сын предудыщего - MemcacheDB, отличается от Memcache тем, что использует BerkleyDB как постоянное хранилище данных. MemcacheDB используется в таких известных проектах, как digg.com, Slashdot.org, wikipedia.org, что уже говорит о многом.
Project Voldemort, который используется в LinkedIn.com, хранит данные хранятся как в памяти, так и на диске, так что сбои питания никак не нарушат целостности данных в отличие от Memcache. Поддерживаются типы данных: структурированные данные (массивы), blob (двоичные пакеты данных) и обычный текст. Сильной стороной является поддержка версионности, то есть каждая единица данных имеет историю версий и изменений, поэтому можно откатываться назад, если что-то записали не то или возникли ошибки. Быстродействие также на высоте: в среднем 10-20 тысяч операций в секунду.
Молодой и быстро развивающийся проект Redis имеет широкий функционал: позволяет хранить не только обычные ключи и значения, но и списки, наборы данных (группы пар ключ-значение), а также производить всего одной командой (и с гарантированным временем выполнения!) сложнейшие операции над такими списками; поддерживается даже сортировка, что является самой сложной и практически не выполнимой командой для всех key-value баз. Данные хранятся не только в памяти, также ведется асинхронная запись в фоновом режиме на диск.
Следующий проект - Scalaris - является транзакционная система хранения, основанной на языке Erlang, при этом работает только с данными в памяти, не используя постоянного хранения на диске. Для отказоустойчивости используют шардинг и репликацию, а также "non-blocking Paxos commit protocol". Примечательно, что проект стал победителем SCALE 2008.
И на последок, рассмотрим две документо-ориентированные БД. Это CouchDb от всем известной компании Apach и MongoDb.

CouchDB ориентирована на хранение данных как документов с иерархией структур и использования JavaScript для написание запросов. Написана полностью на языке Erlang, который очень хорошо подходит для задач, связанных с масштабирование. Об популярности данного продукта в народе может свидетельствовать наличие плагина для работы с CouchDB в такой известной библиотеке как jQuery. Из плюсов хочется отметить поддержку компанией IBM, CouchDB - один из проектов в составе Apache Foundation; также несомненным плюсом является удобство работы с данными. Минусы: низкая производительность, недостаточно подробная документация.

MongoDb - это альтернатива Couchdb, написанная на C++. Отличается лучшей производительностью, широким набором поддерживаемых типов данных, возможностью строить ad-hoc запросы, сохранением данных in-place и хорошо подготовленной документацией. К тому имеет коммерческую поддержку от компании 10gen. Ключевой минус: на 32-битных системах не позволяет создать базы размером более чем 2.5 гигабайта.
На этом закончим наш обзор. Как видите, выбор есть и достаточно широк. Конечно, вышеперечисленные проекты - это не полный список всего, что имеется на рынке key-value БД, в обзор вошли, по мнению автора, самые интересные или известные решения.

В первой части статьи "Проблемы масштабируемости современных веб-приложений" были рассмотрены основные проблемы масштабируемости БД и методы борьбы с ними.
Существует мнение, что не стоит решать проблему масштабируемости раньше, чем она возникнет. С одной стороны, это правильно, ведь эту проблему обеспечивает популярность сервиса у пользователей: чем больше пользователей, тем больше нагрузка, чем больше нагрузка, тем больше проблем. Масштабируемость для традиционных РБД – это проблема денег, и никто не захочет вкладывать их в пустое место, ведь существует вероятность, что сервис не наберет критического количества аудитории. Однако, можно подумать о дне завтрашнем сегодня, как это сделали, например, разработчики известных сервисов Facebook и LinkedIn, которые используют в качестве хранилищ данных сервера key-value БД Memcached и Project Voldemort соответственно. (Тут сразу хочу сделать заметку, что на сегодняшний момент конкретного названия у этого типа хранилищ данных пока нет, существуют различные названия –безсхемные БД (schema-less), key-value БД, распределенная хэш-таблица, распределенная БД, документо-ориентированная БД и другие названия. Условимся использовать для обозначения key-value БД).
Чем же отличаются key-value БД от таких привычных РБД? Сперва ответим на вопрос, что же вообще такое база данных? Конечно же, специальное хранилище структурированных данных, обеспечивающее эффективный поиск и обработку данных. Как хранятся данные? В файлах, имеющих собственную структуру и кешем в памяти. Как обеспечивается поиск и обработка данных? SQL-движком, который принимает команды, выполняет их и возвращает результат. Что такое key-value БД? Это максимально упрощенная база данных со структурой хэш-таблицы. Данные в такой БД хранятся в виде пары «ключ-значение», где ключ является тем же индексом, по нему происходит поиск, обновление, удаление, а значением может быть что угодно. То есть key-value БД строятся на хэш-таблицах, а так же на их разновидности – распределенные хэш-таблицах (DHT).

Если подумать и вспомнить, что же такое родное напоминают эти распределенные хэш таблицы, то окажется, что всем знакомые торрент-сети.
Умные люди на то они и умные люди, чтобы не придумавать велосипедов. А может, они просто ленивые? Вобщем, посмотрев по сторонам и увидев такие старые добрые и хорошие хэш-таблицы, решили приспособить для своих нужд.
DHT — это класс децентрализованных распределённых систем, которые обеспечивают поисковый сервис, похожий по принципу работы на таблицу хешей, и имеют структуру: (имя, значение), хранящиеся в DHT, а каждый участвующий узел может рационально искать значение, ассоциированное с данным именем. Ответственность за поддержку связи между именем и значением распределяется между узлами, таким образом изменение набора участников является причиной минимального количества разрывов. Это позволяет DHT изменять масштаб до очень большого количества узлов и постоянно отслеживать добавление/убавление узлов и ошибки в их работе[http://ru.wikipedia.org/wiki/DHT].
Важное свойство хеш-таблиц состоит в том, что при некоторых разумных допущениях, все три операции (поиск, вставка, удаление элементов) в среднем выполняются за время O(1). Поэтому БД, построенные на хэш-таблицах, отличаются высокой производительностью.
Кроме того, масштабируемость при таком решении является неограниченной благодаря свойствам DHT. При этом в коде взаимодействия сервиса и БД ничего менять не надо, как пришлось бы при использовании любого из вариантов масштабирования обычной БД.
Однако структура данных, дающая огромную производительность и масштабируемость, является плохо приспособленной для привычного SQL-поиска, ведь поиск в key-value БД производится только по ключу, а данные, ассоциированные с ним, могут быть чем угодно. Таким образом, задача обработки данных ложится полностью на приложение. Другими словами, то, что раньше за разработчика делал SQL, теперь придется делать ему самому.

Ярким примером key-value БД является Berkeley DB (BDB). BDB хранит пары «ключ/значение» как массивы байтов и поддерживает множество значений для одного ключа. BDB может обслуживать тысячи процессов или потоков, одновременно манипулирующих базами данных размером в 256 терабайт, на разнообразном оборудованиии под различными операционными системами, включая большинство UNIX-подобных систем и Windows, а также на операционных системах реального времени [http://ru.wikipedia.org/wiki/Berkeley_DB]. Berkeley DB входит в состав многих программ с открытым кодом, в частности, система встроена в Web-сервер Apache и в графическую оболочку Gnome. Все коммерческие дистрибутивы Linux, а также многие разновидности BSD содержат Berkeley DB.
Еще в качестве примера можно привести BigTable, которая является закрытой разработкой компании Google, используемой для хранения структурированных данных многочисленными сервисами и проектами Google. Внутри Google функционирует более 500 экземпляров BigTable (т.н. cells), крупнейший из которых насчитывает более 3 тысяч машин, хранящих свыше 6 петабайт данных. Наиболее загруженные экземпляры BigTable обслуживают в круглосуточном режиме более 500 тысяч запросов в секунду. Впечатляет, правда?
В настоящее время существует несколько проектов, занимающихся разработкой key-value БД. Это Memcached/MemcacheDB, Project Voldemort, Apach Couch DB, MongoDb, Redis, Scalaris и др. Обзор этих проектов оставим на следующий раз

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

Читать подробнее...

Практически все БД, используемые на сегодняшний день в приложениях, являются реляционными (конечно, не стоит откидывать в сторону такую вещь, как ОБД - объектные БД - но их доля очень мала). Типичная реляционная база данных представляет собой набор хорошо структурированных данных в виде таблиц, взаимосвязанных между собой какими-либо отношениями.
Тому, что РБД являются мощным и удобным хранилищем данных, свидетельствует их 30-летняя история. Однако, все хорошо до тех пор, пока интенсивность запросов на выборку или запись данных не перейдет критическую отметку, когда сервер РБД уже не справляется с нагрузкой, и приходится думать о способах решения этой проблемы. И тут-то во всей своей красе встает проблема масштабируемости. Что же такое?
Масштабируемость - способность системы справляться с увеличением нагрузки, сохраняя пропускную способность, при увеличении определенных ресурсов системы. Например, проблемой масштабируемости обладает весь общественый транспорт в час пик, но велосипед, как видно, очень хорошо масштабируется

Проблема масштабируемости серверов баз данных – довольно больная тема. И она становится все более актуальной при росте нагрузки на сервис, когда сервер БД не справляется с количеством запросов на чтение/запись данных. Примеров проектов, которые сталкиваются с данной проблемой, можно привести огромное количество – начиная от новостных сервисов (узкое место – чтение данных) и заканчивая социальным сетями и такими сервисами, как Skype и ICQ. Довольно ярким примером может послужить популярный сервис twitter, у которого совсем недавно были проблемы из-за огромного числа пользователей. Существует несколько подходов к решению проблемы - можно использовать партиционирование таблиц, репликацию или шардинг. Об этих методах можно говорить много и долго, поэтому ограничимся кратким описание каждого из них.
Партиционирование таблиц заключается в разбиении больших таблиц на логические части по выбранным критериям, например, для новостного сервиса, делить новости по дате – ведь самые востребованные новости – это свежие новости. Таким образом, нагрузка распределяется на таблицу по ее партициям.
Суть репликации в синхронном/асинхронном копировании данных с ведущих серверов на ведомые (или возможно тоже ведущие) сервера (master-slave/master-master replication. Репликация – это наращиваемое решение, однако существует предельный максимум слейв-серверов (и обычно он связан с тем, что на каком-то этапе уже мастер становится слабым звеном и начинаются проблемы с записью, а не с чтением).
И последний метод, шардинг, заключается в логическом разделении данных по различным ресурсам исходя из требований к нагрузке. Различают вертикальный и горизонтальный шардинг. Как пример сервиса, в котором используется шардинг, можно привести Skype.
У каждого из этих методов есть свои тонкие моменты, и ни один из них нельзя выделить как панацею.
Но некоторые умные люди нашли решение этой проблемы.
Как же поступили разработчики таких известных сервисов, как Facebook и LinkedIn?
Продолжение следует