niXman,

Интересно, что никто не упомянул о распределеных NoSQL системах хранения (хотя учитывая название форума ничего удивительного в этом нет :) ), которые как раз и появились на свет во многом потому , что традиционные SQL базы данных не обеспечивали нужной производительности для таких систем как Google (факт. родоначальник направления с BiGtable технологией), Amazon (их разработка Dynamo используется самим Амазоном для распределенного хранения информации о продажах - объемы данных сами можете представить). Из ниболее популярных опен-сорсов - Cassandra (если не ошибаюсь изначально была разработана в Facebook) и HBase/Hadoop.

При чем NoSQL означает Not Only SQL. Очень часто эти системы используются как промежуточное хранилище данных обеспечивающее очень быструю запись (за счет чего - отдельная тема, но кратко - данные пишутся в файлы последовательно и периодически отдельным проходом происходит compaction ), а потом данные анализируются, агрегируются и т.д. и пишутся в традиционные СУБД для хранения и обработки традиционными системами , написанными с использованием SQL.
Хотя все больше новых систем проектируется сразу с использованием NoSQL решений.

Основное преимущество - масштабируемость этих систем. Я хорошо понимаю, что на этом форуме собрались адепты и "зубры" SQL технологии , но я думаю вряд ли кто-то может привести пример кластера традиционной SQL СУБД c тысячами серверов и линейным графиком масштабируемости. Также эти системы как правило обеспечивают автоматический data partitioning , re-partitioning в случае потери нода или добавлении нодов в кластер, дублирование информации для failover , распределение нагрузки и т.д.

У каждой технологии ( SQL и NoSQL) есть свои сильные и слабые стороны и области применения. Поэтому надо выбирать исходя из требований, возможного развития системы в будущем, затрат не только на разработку, но и поддержку и т.д.

Peter FИнтересно, что никто не упомянул о распределеных NoSQL системах хранения

Корректировка - уроминание о NoSQL было уже ранее в ответах.

Еще часто ставят In-memory Cache между базой данных и логикой примема/обработки запросов. Системы кеширования могут сливать данные в базу синхроно или асинхроно с указаной задержкой. Я использовал это для того чтобы фактически организовать буффер в памяти для накопления данных и потом записи их в базу "пакетами". Если установить кластер - то потери данных не произрйдет , так как рапределенный кеш реплицирует данные на другой нод. Конкретно систему кеширования я использовал - опен сорс Hazelcast для Джава

IgorKВот всегда почему-то приводят в пример то Амазон, но Фейсбук то еще что-то. Есть в этих системах одно НО, что позволяет "размазывать данные" по куче серверов.
...
Попробуйте размазать данные бухучета и получить потом баланс в реальном времени? Никакой шардинг тут не работает! Поэтому и строят кластера Ораклячие - чтобы иметь доступ ко ВСЕМ данным.

Согласен, потому сразу и написал - что все зависит от конкретной задачи и выбор технологий зависит от многих факторов.
Но даже в случае Фейсбук - не все так просто как кажется , у них-то данные как раз очень взаимосвязаны - по сути это один большой граф , вот сильно упрощенный пример:
- сообщение от пользователя привязано к пользователю , который его написал
- этот пользователь связан с другими пользователями "дружеско-семейными" связями
- у тех польхователей куча своих сообщений, статусов, предпочтений (I like it)
- и т.д.

И они предоставляют свой Graph API чтобы ходить/искать по этим связям и "выворачивать" данные как угодно. И этот API используется рекламными "монстрами" чтобы проводить рекламные компании и в реальном времени отслеживать эффективность, смену предпочтений и т.д.

Но если мы вспомним с чего началась эта дискуссия - это быстрая запись в базу большого объема информации. Вот например ссылка
http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html

В которой приводятся результаты тестирования Кассандры Нетфликсом (один из крупнейших провайдеров видео через Инет в Штатах)
Тестировали в Амазон облаке, получили 1.1 млн записей в секунду с репликацией в три зоны, итого 3.3 млн. записей в секунду.
В статье есть график масштабируемости - фактически линейно вплоть до 350 серверов.
К сожалению статья на англ. но наверное можно автоматом приличный перевод получить в Хроме или еще как.

Это один из примеров, таких бенчмарк можно много накопать.

Опять же, это как альтернативная точка зрения. Даже если традиционная технология лучше подходит под ваши требования - всегда полезно узнать что-то новое, это может натолкнуть на какие-то свежие или оригинальные идеи или подходы и применить их даже в рамках традиционной SQL или любой другой платформы.