Ищю литературу по работе со сверхбольшими базами данных

Тема в разделе "Базы данных", создана пользователем jabbaxatt, 18 апр 2012.

Модераторы: latteo
  1. jabbaxatt

    jabbaxatt Добрый модератор

    Moderator
    Регистр.:
    21 янв 2009
    Сообщения:
    878
    Симпатии:
    411
    Собственно смысл в заголовке.

    - С чего начинать знакомство (на русском и с понятным, логичным описанием)?
    - Какая лучше всего литература на русском?
    - Как вообще работают с массивами данных по несколько терабайт(десятков терабайт)?
    - Что используют в качестве СУБД Яндекс, гугл, фесйсбук, твиттер и сапа?
    - Где почитать по русски про MongoDB?
    - Где прочитать понятно про сервера master-master и master-slave?

    P.S. пока чувствую себя полным дебилом не въезжающим в основы.
     
  2. Da1VeR

    Da1VeR Постоялец

    Регистр.:
    22 фев 2012
    Сообщения:
    128
    Симпатии:
    21
    В банках, больших торговых центрах и компаниях где количество клиентов от 2 млн. используют специально заточенное железо - IBM AS/400 и подобные, но там в основном базы DB2 и если нужны еще какие-то скрипты - системный язык кобол... и они рассчитаны на очень большое количество запросов... но сами железки дорогие.... Если проект подразумевает стабильность - врятли есть что- лучше... (если остановишься на AS/400 и нужна будет литература - пиши в ЛС)
    Если по поводу терабайтных массивов данных и сапа - то Оракл... литературы в интернете много... + если сап купленный - у них на офф. сайте огромная складчина литературы, что и как настраивать и при каких нагрузках.
     
    jabbaxatt нравится это.
  3. casinolot

    casinolot

    Регистр.:
    22 окт 2010
    Сообщения:
    548
    Симпатии:
    84
    Я вот, на основе своего опыта, скажу, что если вы будете работать в гос.учереждениях типа пенсионный фонд, то это то что посоветовал предыдуший оратор.
    А вот в больших компаниях в основном ORACLE используют, могу посоветовать как только начнете изучать ORACLE сразу паралелльно изучайте ее оптимизацию, т.к. СУБД очень тормознутая, и честно скажу на это надо решится чтобы посвятить себя таким БД.
    Например у нас внедряют ORACLE уже полтора года и всё постоянно ложится и поддтармаживает.
     
    jabbaxatt нравится это.
  4. casinolot

    casinolot

    Регистр.:
    22 окт 2010
    Сообщения:
    548
    Симпатии:
    84
    Вот еще ,как-то начал интересоваться, и наткнулся, что современные гиганты, типа Гоогла уже используют NoSQL
    Т.е. явно не оракл, нашел неплоху статью правда на англицком.
    http://highscalability.com/google-architecture
    http://abrdev.com/?p=1071
     
  5. sparsame

    sparsame Постоялец

    Регистр.:
    20 авг 2011
    Сообщения:
    85
    Симпатии:
    11
    ну смотря что ты хочешь делать с этой бд.....Если не сильно часто использовать все бд сразу то советую почитать про кубические бд....Они кстати и применяются в банковских системах, по крайне мере в 1 банке точно)))
    опиши бд
    1 количество ячеек
    2 как часто используются
    3 Размер ячейки
    и т.д. когда все распишешь будет уже проще моделировать дальнейшую схему работы с этой бд....Не всегда кстати нужно сумашедшие деньги чтобы оптимизировать бд...Общий размер базы не такая страшная вещь как о ней пишут))))
     
  6. Da1VeR

    Da1VeR Постоялец

    Регистр.:
    22 фев 2012
    Сообщения:
    128
    Симпатии:
    21
    2sparsame
    Я так понимаю кубические бд Вы имели в виду OLAP ?:
     
  7. sparsame

    sparsame Постоялец

    Регистр.:
    20 авг 2011
    Сообщения:
    85
    Симпатии:
    11
    да..именно их....но опять же все зависит от того что требуется от бд..........
     
  8. lift

    lift Читатель

    Заблокирован
    Регистр.:
    1 июл 2007
    Сообщения:
    2.226
    Симпатии:
    1.378
    jabbaxatt
    Твиттер - MySQL + FlockDB пруфф на офф инфу по моим прикидкам инфы порядка 100-150 тб
    Фейсбук - MySQL пруфф на офф инфу по моим прикидкам порядка 2-3 пб инфы в базе
    Вконтакте - MySQL + "собственная разработка на С" пруфф на офф инфу по моим прикидкам объем порядка 1-2 пб.
    У википедии порядка 50 тб (могу посчитать прямо точно, у вики с этим просто :)) в MySQL на сколько я понимаю без сильных ее доработок вообще, чисто на архитектуре самой базы.
    Yahoo - PostgreSQL без пруфа, по офф данным 5 лет назад была весом в 2 пб, сейчас думаю около 5 пб.
    У сапы... Ну как говориться "я знаю человека, который знает человека, который знает человека, который..." в общем там мускул и ничего архинавороченого. По крайней мере было.
    У гуглы нет базы данных как таковой. У них используется своя концепция. Там работает кластер, с распределенной файловой системой определенной конструкции, которая сама по себе является базой данных в бОльшем смысле этого, чем традиционные ФС типа fat, ntfs, ext и прочих. Самое близкое из того, что можно пощупать, это ReiserFS но она только под линями, да и то не под всеми, и не распределенная а монодисковая (хотя рейды никто не отменял и пентобайт одним массивом с ней сделать в принципе реально).
    У яндекса там тьма покрытая мраком. Они слишком секретно-закрытые все. Но из нескольких источников есть то, что они юзают по крайней мере местами MySQL и PostgreSQL. Но это не те места, с которыми их пауки общаются.
    Если еще надо, могу еще кучу накидать инфы по теме и с пруфами и без пруфов. Коллекционирую подобную инфу ))))
    Если говорить глобально, то
    целиком и полностью поддерживаю данное утверждение. Если с умом подойти к структуре базы, к тому, как с ней будет происходить работа, к конфигам серверов, можно вертеть очень большими объемами без проблем совершенно. Та же самая вика по умолчанию из коробки будет работать корректно с базами в 50 тб, хотя если брать обычный шаред хостинг, при работе с ней скорее всего возникнут проблемы, потому что она будет "тяжелой" для него во многом именно из за своей специализации на большие объемы.
    Про гуголу писал выше. У нее конкретно нельзя сказать что она на файлах или на базе, у нее своя смесь получается. Но глобально, если подходить к решению конкретных вопросов, то может оказаться, что использование смеси файлового хранения + баз с парами ключей будет самым быстрым решением. Фейсбук, твиттер и вк юзают идеологически похожие решения, как минимум один из них при этом данные, полученые в сопоставлении, хранит пофайлово а не в базе. Вот рядом буквально лежит диск как раз с таким файолом, там не по тематике этого форума контент, но суть в том, что вот уже пару лет народ из коммюнити по тому контенту не смог придумать такой архитектуры базовода, чтоб десятки миллионов пар данных хранились бы там бучше, чем в пофайловом режиме :) Сейчас на том софте из того контента выборка произвольная занимает миллисекунды в пофайловом режиме, а на любом из базоводов, который пытались прикрутить для этого она занимала секунды.

    Написал сейчас тут много, красиво и с понтами, но потом перечитал пост твой, строки про нуба и стер. Попробую написать максимально просто как смогу :) В общем читать там по большому счету нечего. Если ты ставил ось и ставил базовод с настройками всего этого, то можно сказать, что ты все и так знаешь в общих чертах. Различия есть в деталях. Делать мастер и слейв сервера называется одним словом - кластеризовать. Так вот, кластеризовать можно много чего и по разному, в зависимости от потребностей. Например тебя есть большая база. реально большая, которую на одном сервере не раскрутишь. Ну или такой мощный сервер будет стоить больше, чем несколько более простых. В таком случае гуглиш мануал, по настройке кластера для своего базовода. Если ты ставил и настраивал сам базовод, то этот мануал будет тебе как 2 пальца об асфальт разобрать. там добавляется несколько строк в конфиг обычно и реально нет ничего архисложного. В зависимости от конкретного базовода может быть несколько режимов работы всей этой конструкции:
    на каждом узле будет полная копия базы и распределяться будет только вычислительная нагрузка (аналог RAID0 в дисках)
    на каждом узле будет часть базы и распределяться нагрузка будет в зависимости от того, к какой части базы идет обращение (аналог RAID1 в дисках)
    Есть иногда еще конфиги, когда на части серверов идет дублирование информации, а на части серверов идет распределение вычислительной нагрузки, по аналогии с дисками это типа RAID10, 5 и 6.
    Просто читаешь мануал под свой базовод и думаешь, что тебе надо.
    Если у тебя базовод твой поддерживает только разделение нагрузки по серверам с частичным копирование (RAID0) и при падении части одного сервера у тебя упадет все, а тебя это не устраивает но сам базовод тебе подходит, то можно кластеризовать отдельно ось. Например у тебя есть 1 мастер и 2 слейв сервера на мускуле, на каждом храниться по 100 гигов базы и эти части образуют единую базу в 300 гигов но если упадет один из серверов, то упадет все. В таких случаях можно сделать силами операционной системы (виндос сервер 2003 и выше имеет такую остнаску, гуглиться по microsoft cluster server куча мануалов по 2003 серверу и по их аналогии в 2008 делается все, под линями, сорри, не имел опыта, по конкретным вопросам не подскажу тебе). Так вот, ты для своих 3-х серверов базовода берешь 6 физических серверов и настраиваешь на них пару абсолютно одинаковых класстеров из 1 мастера и 2 слейв серверов. После этого силами винды настраиваешь балансировку между парами мастер-серверов и парами одинаковых слейв-серверов с тем, чтоб в любой момент они для базовода выглядели полностью одинаково. И силами же операционки после этого настраиваешь балансировку всего этого. В такой ситуации базовод будет думать, что у него всего 3 сервера, а операционная система будет подменять любой из этих серверов при отказе или при большой нагрузке сама, никак не касаясь работы базовода. Получишь систему, в которой можно отключить любой из серверов (сгорел например, или ремонт или еще что-то) и система целиком не упадет. Под иксы есть такие же решения, такие же коробочные и так же гуглятся под конкретные операционки.
    В принципе это все, что можно сказать про мастер и слейв сервера не беря в руки конкретные примеры базоводов и при необходимости (если базоводы сами не умеют) операционок.
     
    smalllamer, o_nix, Da1VeR и 5 другим нравится это.
  9. dandandan

    dandandan

    Регистр.:
    7 авг 2008
    Сообщения:
    975
    Симпатии:
    255
    lift, а как быть, если сервера планируется размещать в разных датацентрах ? Т.е. если грохнется 1 ДЦ, чтобы сайт работал из другого ДЦ.
     
  10. lift

    lift Читатель

    Заблокирован
    Регистр.:
    1 июл 2007
    Сообщения:
    2.226
    Симпатии:
    1.378
    dandandan
    Мы говорим абстрактно? Распараллелить операционки между ДЦ думаю будет можно. Например в каждом ДЦ поднять N серверов, собрать их в единую сетку, после этого виртуализовать на них N виртуальных серверов и представить им всю конструкцию уже как локальную сетку. Естественно между ДЦ распределить виртуальные сервера так, чтоб они продолжали бы работать если отключить не отдельную виртуальную машину а ДЦ целиком. Это только один вариант, возможно в частных случаях даже не надо будет делать прокладку в виде виртуализации серверов, возможно их можно будет собрать в единую сеть и в "железном" виде. Если под конкретную задачу делать решение, то возможно там можно будет обойтись и без мощных каналов с анлимом траффика для синхронизации всего этого добра. А так, можно хоть по одному серверу в нескольких ДЦ собрать и так же их юзать.
    Если кластеризовать базоводы, то тут может быть все вообще на много проще, на сколько я помню MySQL при распределении нагрузки (когда мастер и слейв сервера имеют полный набор баз и только распределяют между собой вычислительную нагрузку) это все без разницы, там в конфиге наддо только IP серверов прописывать и то, что они в одной локалке должны быть никак не регламентировано, тоесть через инет в разных ДЦ работать они смогут спокойно. Опять таки все упирается в качество и пропускуную способность канала между серверами и способ синхронизации информации, который зависит от конкретных осей, конкретных базоводов и конкретных задач.
    Кроме того, очень хорошо, что ты в качестве примера выбрал именно различные ДЦ
    Более предметно с конкретным сложным примером (многабукафф) :
    Вот накидал картинку, прошу не пинать сильно, накидывал быстро, а то на пальцах сложно объяснять:
    [​IMG]

    Серые прямоугольники - ДЦ. Произвольное количество, я нарисовал 3.
    Желтые прямоугольники - физические сервера. В моем примере их по 3 на ДЦ, итого 9.
    Красные прямоугольники - схематически физические каналы между серверами.
    В каждом датацентре стоит несколько физических серверов, которые настроены на работу между собой и между которыми настроены физически сетки. Они объединены в единую группу в между датацентрами и настроены без балансировки. На них стоит любая ось с виртуализацией (например бесплатный Hyper-V Server Core от МС) и эта ось служит прокладкой между физическим железом и нашей рабочей структурой. Единственное, что они могут делать кроме виртуализации и создания общей сети физического уровня это первоначально балансировать нагрузку. Тоесть тупо обмениваться между собой информацией периодически, у кого сколько нагрузки по виртуальным машинам и в случае, если собственная нагрузка большая а есть свободные ДЦ то отправлять нагрузку туда. Это не сложная задача, реализуется чем угодно от готовых оснасток осей до мелких самописных прог или скриптов.
    Зеленые прямоугольники - виртуальные сервера. На них стоит уже сама рабочая кластеризованая (если надо) ось и кластеризованый (если надо) базовод. У меня в примере 18 виртуальных серверов.
    Синие прямоугольники - виртуальная локальная сеть. Она проложена поверх физической сети и ей нет разницы, лежит ли она в рамках одного ДЦ или раскидана между ними. На схеме все виртуальные сервера соединены в единую локальную сеть, они не знают, где они находятся физически, как сконфигурирована реальная сеть, где расположены ДЦ и остальное. Ей на это пофигу.
    Так как тема у нас про базы, то на каждом виртуальном сервере стоят базоводы, на нескольких серверах мастера - на нескольких - слейвы и между собой они не балансируются средствами базовода. Но так как они все крутятся на единой платформе виртуальной оси с балансировкой нагрузки, то сама ось в каждый конкретный момент времени решает, какой мастер или слейв сервер получает нагрузку, следуя при этом определенным алгоритмам (чтоб не заменить мастер сервер слейвом или слейвы не перепутать например).
    Черный прямоугольник у нас динамический DNS
    Синие стрелочки - пути запроса
    Розовые стрелочки - альтернативные возможные пути запроса.
    Как это все работает:
    1) Нам поступает запрос.
    Он адресован по имени домена, тоесть обрабатывается динамическим днс и он решает, что его надо отправить во второй ДЦ. Альтернативно он может его отправить в 1 или 3 ДЦ, но вот так вот решилось, что он отправился во второй.
    2) Во втором ДЦ его встретил физический сервер, держащий часть виртуалок. Он видит, что машина у него не сильно загружена и отправляет запрос к себе на виртуалку master2. Как альтернатива он может отправить ее на другую виртуалку или в другой ДЦ.
    3) В виртуальой машине операционка определяет, что сервер master2 завис, а master1 и так нагружен. Но он видит, что есть свободный сервер master1 в ДЦ3 (точнее он не видит ДЦ, он видит, что есть свободныйв данный момент мастер-сервер) и отправляет запрос в него.
    4) Сервер обрабатывает запрос, отдает его на физический сервер в ДЦ3 и этот физический сервер отдает запросчику готовый ответ.
    Схема примерная. Если кто хочет мне сказать, что там еще что то должно быть, пусть сам рисует и сам строчит большие посты с этим все, я с удовольствием их почитаю и покритикую :) Схема примерная и всего один из вариантов решения.
    Что будет, если что-то сдохнет:
    Допустим, у нас случился форс-мажор, и в ДЦ3 сдох сервер 2.
    Нам будет это совершенно параллельно, потому что на сервере останется свободный master1-сервер и его слейвы slave21 (полное зеркало сдохшего на втором серевере slave11 ) и slave12 со своей копией slave22. Сама ось в реалтайме подменит вылетевшие сервера оставшимися на физических у себя или на любом другом сервере в любом другом датацентре.
    Если у нас сдохнет весь датацентр, то все повториться точно так же, оставшиеся виртуальные сервера сбалансируют нагрузку а динамический ДНС просто не будет в сдохший ДЦ посылать запросы до тех пор, пока он не отживет.
    Из-за того, что виртуально у нас все собрано в единую сеть, запросы могут обрабатываться на любой свободной конфигурации серверов, тоесть например поступил запрос на master2 в ДЦ1, а в качестве слейвов для его обработки могут выступить свободные в данный момент времени slave11 в ДЦ3 и slave22 в ДЦ2. Сама синхронизация виртуальных серверов вполне может проходить на уровне виртуальных машин и существующих технологий синхронизации снимков машин, тоесть виртуальная сеть даже не будет знать, что ее элементы синхронизируются.
    Кроме того, мы можем в любой форме и в любом порядке отключать или подключать физические сервера и датацентры, главное, чтоб у нас в любой момент времени работало 2 из 9 физических серверов и всеравно где - нагрузка будет сбалансирована. По производительности она будет равна 9 отдельным серверам. При этом скорее всего может проиграть им если их сгруппировать по 3 для создания 3-х мастер-слейв систем (проиграет в 2 раза) либо если на каждом собрать по отдельному базоводу (проиграет по количеству обработаных запросов в 1.5 раза). Но в сумме она будет делать то же количество работы, но с гораздо больше гибкостью и решенными вопросами по распераллеливанию всей системы.

    Это был только один из примеров. Если наш базовод поддерживает и репликацию базы на несколько мастер-слейв серверов и балансировку нагрузки между несколькими мастер-серверами, то все примочки типа виртуальной сети и балансировки силами операционки нам не нужны. Но этот вариант уже проще, если вы поняли мой пример, этот пример будет понять уже легче и проще.
    Всю подробную информацию можно легко нагуглить. Нет сложностей с манулами по виртуализации и созданию между несколькими физическими серверами пусть и в разных ДЦ единой виртуальной сети виртуальных же машин. Нет никаких сложностей с мануалами по кластеризации конкретных осей и балансировки нагрузки между нодами, ее составляющими. Нет никаких сложностей с манулами по кластеризации конкретных базоводов. просто берите то, что надо под конкретную задачу и читайте.
    п.с. Сам я в рамках грубо говоря одного ДЦ распараллеливал MySQL без проблем. Мне не нужно было несколько датацентров, по этому задача не стояла такая. Взял на одной машине поднял виртуалку, поставил туда мастер и 2 слейв мускула, сделал отдельно им фронтэнд, расписал кто как физические ресурсы кушает и получил в локальной задаче примерно в 3.5 раза прирост производительности на том же железе.

    п.с. Подзадолбался что-то :) 9к уникального текста ))) С праздником всех, если вопросы будут - отвечу не раньше 2 числа.
     
    dandandan и jabbaxatt нравится это.