100 баз даних потенціалу TeraBytes - ресурси та часові оцінки

Я працюю над обчисленням "зворотного боку конверта" для налаштування бази даних звітів 100 ТБ. Я шукаю думки у експертів тут. Пропоноване середовище:

1. Ємність для зберігання ~ 100 ТБ
2. Столи ~ 200, розміри від 1 ГБ до 5 ТБ. середній розмір може лежати між 100GB-200GB
3. ETL - завдання можуть вимагати з'єднання між таблицями розміром 10 мільйонів рядків, при цьому клавіші з'єднання становлять від 10 байт до 500 байт. такі приєднання повинні закінчуватися за 2–5 хвилин
4. Live Selects - спочатку цікавить лише вибрані швидкості. повинна підтримувати 500 вибору / секунду. Оновлення / секунди буде порівняно набагато меншою кількістю, і їх можна ігнорувати для цієї вправи.
5. потрібна наявність 24х7. Для обслуговування вибраних дзвінків (із реплікацією даних) повинні бути доступні 2 незалежні сервери БД.

Запитання:

1. В даний час я дивлюся на Oracle. Яким є ваш досвід роботи з іншими комерційними (або) відкритими рішеннями для великих баз даних?
2. Які апаратні ОС ви бачили, що вони найкраще працюють? Я планую на Linux на Dell.
3. Чи обов'язкове мережеве сховище, наприклад NetApp? Які проблеми ви передбачаєте при використанні комерційних поза поличковими дисками?
4. Як тільки апаратне забезпечення та ОС будуть готові, скільки часу ви відведете на налаштування, налаштування БД, зберігання тощо.
5. Які композиції колективу найкраще працювали в спостережуваних умовах? Я маю на увазі різні адміністратори (ОС Admin, Oracle DB Admin?), Необхідні для управління та керування такою установкою. Скільки з них може знадобитися для досягнення 24x7 режиму роботи.
6. Будь-яке наближення / діапазон щодо ліцензій DB, витрат на мережеве зберігання.

Я знаю, що я не маю всіх деталей щодо оточення. Я не шукаю точних деталей, наближення достатньо. Хоча на деякі питання найкраще можуть відповісти менеджери, мене цікавить перспектива адміністратора. Я ціную ваш внесок.

Перші враження

1. Залежно від ваших вимог до продуктивності, 100 ТБ - це досить агресивний обсяг даних. Якщо ви хочете Oracle, вам слід переглянути їх системи Exadata. Також погляньте на пропозиції від Netezza або Teradata. За допомогою цього обсягу вибору ви можете подивитися на передній частині, що базується на OLAP, або, принаймні, досить агресивно використовувати матеріалізовані подання та переписувати запити. Ви не отримаєте 500 сканувань на секунду з нічого.
   
   Що стосується менш суворих вимог до затримки, ви можете розглянути більшу кількість маркованих даних, щоб надати можливості звітування для вашої спільноти користувачів. У цьому випадку SQL Server і SSAS можуть бути варіантом для маржи даних, оскільки ліцензування на більшій кількості серверів буде дешевше, ніж намагатися зробити те ж саме з Oracle.

2. Див. (1). Звичайне обладнання в архітектурі спільного диска, ймовірно, буде повільним для цього набору даних про розмір.

3. НІ! Якщо хтось пропонує NFS, дайте їм гарного удару. Або пряме з'єднання для зберігання, або кілька контролерів SAN з великою кількістю контролерів середнього класу. Подумайте, можливо, кілька десятків контролерів серії MD3000 або щось подібне - якщо ви не ходите на платформі "великих даних", побудованої за призначенням.

4. Отримайте спеціаліста зі зберігання, який має досвід роботи на платформах зберігання даних PB. Ви, мабуть, готові до важливої ​​роботи з розробки ETL та багато тестувальної роботи, якщо вам доведеться зустріти жорстку угоду про надання послуг.

5. 24x7 на сховищі даних є найкращим в найкращі часи. Це операційна платформа звітності? Можливо, ви можете трохи детальніше розглянути свої вимоги.

6. Сфінктер дороговартісний і залежить від ваших вимог. Востаннє я бачив (пару років тому) Netezza звинувачував $ 20000 / ТБ для систем TwinFin, зробивши вашу платформу $ 2 млн за 100 ТБ плюс вартість резервного сервера та резервного обладнання. Exadata, я вважаю, трохи дешевший, але в мене немає ніяких цін.
   
   Погляньте на Netezza, Exadata та платформу Teradata для порівняння та витрат на Ab Initio як інструмент ETL.

Це досить агресивний набір вимог - 24x7 на сховищі даних зазвичай не виконується, а обсяги даних є досить великими, щоб поставити вас у сферу платформи "великих даних". Якщо у вас є вимоги до експлуатаційної звітності, вам слід уважно подивитися, що це таке. Тримайте його окремо від вашої аналітики, якщо у вас немає конкретної причини (наприклад, каналу даних з низькою затримкою ринку). Змішування оперативних та аналітичних вимог на одній платформі - погано.

Я думаю, що вам дійсно потрібно звернутися до фахівців, щоб оцінити свої вимоги. Без уважного огляду на те, що ви намагаєтесь досягти всього, що я можу дати, - це кілька емпіричних пропозицій щодо того, що робити чи не робити.

Деякі інші варіанти, які слід враховувати при обробці таких великих обсягів даних, включають:

1. Все, що опублікував @ConcernedOfTunbridgeWells
2. Greenplum від EMC
3. Паралельний сховище даних від Microsoft

Не плануйте нікуди скуповувати витрати на обладнання. Система з такими специфікаціями коштуватиме вам великих грошей.