Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9   вперед  Ctrl      все
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
Областной ЛТП
VoltDB
Это 125МВ/сек минус TCP издержки - пускай чистыми 100МВ/сек. Скажем, Ваша база 600ГВ и распределена на 5-узловом кластере. Значит нужно прочитать и потом записать из памяти одного нода в память другого в общей сложности 600ГВ данных, параллельно используя 5 сетевых интерфейсов с пропускной способностью 100МВ/сек каждый. То есть, полностью перепарционировать 600ГВ база займет около 20 минут.
Ноды с дисками 200МБ/с случайного чтения+записи, пятью сетевыми картами, терабайтом оперативки и соответствущей шиной. Недшевенький кластерок получается с масштабируемостью до всего-то 5+1 нод.


Пример выше основан на 5-ти серверах, каждый с 128ГВ памяти и 1ГигЕ сетевой картой. Так как речь идет об in-memory базе, диск в моих расчетах не фигурировал. Конкчно, диск нужен, но ничего особенного. В любом случае, такая система была бы очень недорогой. И кстати, на железе даже в такой конфигурации хорошо спроектированной приложение показало-бы, по крайней мере 100-200 ьысяч транзакций в секунду. Даже для очень сложного milti-site приложения, я думаю, тысяч 50-75 транзакций в секунду вполне реально, а то и больше. Кстати, масштабируемость такого кластера была бы очень высокой - ведь компонентов общего пользование (кроме сети), которые могли бы стать "бутылочным горлышком" просто нет. Это, собственно, и есть классический пример shared-nothing архитектуры кластера.
7 янв 14, 20:16    [15384590]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
dbms_photoshop
VoltDB
То есть, полностью перепарционировать 600ГВ база займет около 20 минут.
Допустим это так, только вот изменение настолько ключевое, что потребуется регрессионное тестирование всей системы.
И долгие разговоры с начальством про выделение ресурсов на это.
А в реальной практиве подобные изменений далеко не редкость.


Очень резонное замечание - поверьте, мне не раз приходилось сталкиваться с подобными вещами. Но ведь процесс внесения изменений в систему не зависит от платформы - если требования системы к надежности таковы, что регрессивное тестирование необходимо при внесении изменений в систему, то оно необходимо на любой платформе, то ли это Оракл, то ли это MySQL, то ли это что нибудь еще. А "долгие разговоры с начальством" - это вопрос больше организационный, чем технологический. Это больше из серии "А что будет, если мы своих людей новым технологиям выучим, а они потом уйдут?! - А что будет, если мы их не выучим, и они останутся?"
7 янв 14, 20:46    [15384684]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
...Но любую идею можно довести до абсурда. К примеру вызывать на обновление ПО специалистов из США для каждого сервера в отдельности (с оплатой гостинниц и самолетов как это происходит сейчас), естественно затраты растут прямо пропорционально количеству этих SN независимых нод.


Не знаю я кто такую бизнес-модель покупает, но могу только сказать, что для американских поставщиков гораздо более выгоднее пригласить персонал российского заказчика в США для подготовки и обучения. Т.е при продаже систем обычно поставщик берет на себя обязательства по подготовке и обучению определенного количества специалистов заказчика, как правило в своем тренировочном центре; иногда, на ежегодные курсы повышения квалификации.
7 янв 14, 21:10    [15384780]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
Капитан очевидность на проводе
VoltDB
пропущено...


А еще можно свой оптимизатор запросов на стороне сервера приложений написать. Это чтоб если РНР коду данные из двух нодов могут понадобиться... Или больше... Мало ли, может в запросе кроме голого SELECTа еще и суб-запрос есть... Ну или, недай бог, JOIN какой...



В случае проектов Facebook, Twitter и прочих - подобный вопрос, под названием запросы с джойнами делаются не на сервере БД, а строго и исключительно на сервере приложений - возникает автоматически после наверное уже четвертого физического сервера баз данных (ну не могут реляционные БД больше в кластере, особливо MySQL). Там правда возникают еще и сопутствующие вопросы (как правильно управляться с этими кешами в памяти), но то дело такое.

Стоит понимать, что классическая ACID модель - это обобщение под некие виртуальные гипотетические требования бухгалтерского учета (тут дебет, тут кредит, и ни дай бог чото рассогласуется, или перехлест обновлений остатка по счету пойдет).

А для реальной жизни такие жесткие ACID требования, какие выдвигает/предлагает реляционная СУБД - они обычно и нафиг не нужны, при грамотном дизайне приложения (даже бухгалтерского).


VoltDB
А еще, можно вообще все данные на сервере приложений хранить. Например, в текстовом файле... Нету СУБД - так и разбираться не некому, куда за данными ходить...

И? Они у них так и хранятся, в key-value хранилище. Локальное memcache хранилище, промах в который приводит к походу в MySQL, за... те-же самым key-value. Никакой внутренней структуры value не предусматривается вообще (по причине того, что в MySQL ALTER TABLE отправляет базу данных в долгое бессознательное), только ключ и атомарное значение по нему - строка/число/дата. Одна таблица, две колонки. Первая из которых единственных индекс - красота.

Правда миграция данных у них отдельная побоболь, но на самом деле не страшно - ну потеряют какие фоточки или "мессаги" за 2010-й год, так господи, кому они нужны?

А то что тормозит все это нагромождение безбожно (а ну-ка, сходи 200 раз за key-value, чтоб страничку прорисовать), так это просто - всегда можно поставить с миллион серверов в датацентр, деньги то бешеные с рекламы и прочих IPO и так текут, чай не разоримся (те самые 200 запросов SELECT value FROM the_table WHERE key = :key можно делать на 200 разных серверах одновременно, для текущего запроса Васи Пупкина, красота, быстрота!).


Мне кажется мы с Вами говорим о двух абсолютно разных вещах. Мой комментарий был в ответ на Ваше утверждение,что разработчики реляционных СУБД("средств вроде mysql") "пишут обобщенные решения которые должны удовлетворить всех", а также "делают довольно глупые, неэффективные, зато многим нравящиеся универсальные решения".Вы также, как мне кажется, предлагаете клиентскому приложению не полагаться на СУБД в том как искать нужные данные, а разработать "свой менеджер соединений в пуле соединений на стороне сервера приложений, который как раз отправляет страдающий PHP код на строго нужный сервер БД". Вполне может быть что я не правильно Вас понял, но если Вы это предлагаете в контексте реляционной СУБД, то по всей видимости, такое клиентское приложения будет очень сложным (и, соответственно, дорогим) т.к такому приложению нужно будет знать не только где найти данные, но и как выполнять сложные запросы. Другими словами, с точки зрения бизнеса, может оказаться, что разработка такого приложения - "игра, не стоящая свечь". Если же Ваше предложение сделано в контексте NoSQL, то это совсем другое дело - в этом случае, боюсь, выбор решений небольшой т.к такие системы по определению не поддерживают структурных языков запросов. Но в этом случае, предмет дискуссии, наверное, сводился бы к совсем другому, а именно, "А что лучше, SQL или NoSQL?". Хотя в последние пару лет эта тема является предметом для повсеместных и очень горячих споров, я лично, склоняюсь к точке зрения, что если бизнес данные имеют явно-выраженную структуру (например, банковская транзакция), то не использовать для обработки таких данных широко-распространенные и хорошо-понимаемые языки структуированых запросов, наверное, особых причин нет. Если же данные, по каким-то причинам, имеют не явную структуру(например, текст или ДНК-данные) или же сложную много-уровневую структуру (например, URL-адреса), то, соответственно, и хранить-обрабатывать их нужно другими средствами (кстати, NoSQL только один из многих возможных инструментов). Разрешите мне Вам привести пример из реальной жизни, связанный с применением NoSQL/SQL.

Есть одна контора, занимающаяся проблемами Environmental Control Systems. В двух словах, разрабатывают датчики и системы для сбора и обработки данных о среде т.к температура, влажность, вибрация, радиация итд. Системы дожны собирать данные и позволять не только анализ "исторических" данных (т.е что происходило вчера), но и много аналитики в более-или-менее реальном времени (т.е несколько минут. и даже секунд назад). Так вот, разработали систему с реляционной СУБД на бэкенде, потестировали с парой заказчиков - работает отлично. Спрос на аналитику рекой потек, причем на разного рода аналитику, и собирать надо в одну базу. Аналитические приложения ребята, естественно, разрабатывать не стали и закупили немалое количество готовых пакетов от десятка всяких поставщиков - дэшборды там всякие, графические экраны итд. Все пакеты разработаны получать данные посылая SQL-запросы в любые JDBC/ODBC базы (очень, кстати, популярно у производителей аналитических решений). В какой-то момент, нагрузка на систему стала увеличиваться и достигла точки, что пропускной способности этой реляционной СУБД стало катастрофически не хватать. Тут дело даже не в том было, что запросы медленно выполнялись, у них сама база "виснуть" стала в пиковую нагрузку, и, соответственно, тормозить контролеры которые синхронно данные с датчиков качали. Попытались железа добавить - помогло, но не надолго. В общем, похоже, нужен кэш... Ребята грамотные, да и дело-то, собственно, не сложное - решили посмотреть, что получится, если перед базой Редис поставить, т.е очень быстрый буффер, но правда key-value. Т.к Редис SQL-запросы, которые купленные аналитические приложения генерируют, не поддерживает, решили переходник сделать, который от этих приложений SQL-запросы через JDBC/ODBC получает, а потом разделяет на два: один в СУБД шлет (т.е SQL), а второй - конвертирует SQL в их внутренний формат key-value и затем шлет в Редис. Потом, соответственно, ждет результатов из обоих мест, соединяет вместе преобразованные key-value данные с результатом SQL-запроса, потом строит окончательный результат и посылает его через тот-же JDBC/ODBC интерфейс обратно приложению-клиенту. Кстати, клиент-то не один - их много, и все разные запросы шлют, т.е в переходнике все эти конкурентные процессы тоже как-то управляться должны. Вообщем, подумали ребята, проект интересный, но долгий, да и почувствовали, что не потянут (они больше по датчикам-контроллерам да аналитике, чем серверы писать)... Да и посчитали сколько такая разработка стоить может - получилось, что не окупится такая штука много лет.
8 янв 14, 02:11    [15385401]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Капитан очевидность на проводе
Guest
VoltDB
Другими словами, с точки зрения бизнеса, может оказаться, что разработка такого приложения - "игра, не стоящая свечь". Если же Ваше предложение сделано в контексте NoSQL, то это совсем другое дело - в этом случае, боюсь, выбор решений небольшой т.к такие системы по определению не поддерживают структурных языков запросов.

Решение с шардингом (менеджер пулов-балансировщик нагрузки) одинаково применимо и к SQL, и к NoSQL решениям, это раз.
Два - NoSQL решения также предусматривают структурые языки запросов, ознакомьтесь для начала с Cassanrda и MongoDB.
В т.ч. возможны и кросснодовые джойны, хотя это в общем случае еще та глупость.

Кроме того, никто не мешает к любой NoSQL базе ходить через MySQL - все что нужно, это понаписать свой движок, взяв пример движка CSV как основу (там порог вхождения очень низкий).

VoltDB
Но в этом случае, предмет дискуссии, наверное, сводился бы к совсем другому, а именно, "А что лучше, SQL или NoSQL?".

Не лучше ни то, ни другое. NoSQL - отличное решения для задач класса OLTP, SQL - это сейчас больше удел исключительно DWH.
Делать на SQL высоконагруженную OLTP систему (более 5 операций в секунду) - это признак полной неадекватности разработчиков.

При этом оптимальным является решение которое комбинирует оба варианта, т.е. одна и та-же физическая база данных доступна в разных режимах разными средствами. Для OLTP ходим в нее напрямую как в NoSQL (с гарантированным временем реакции, близком к realtime), для отчетов и аналитики - через MySQL плагин какой (с минимальным приоритетом процессов чтения этих данных).

К примеру в MySQL такое решение уже существует http://dev.mysql.com/doc/refman/5.6/en/innodb-memcached-intro.html .
Т.е. можем и SQL запросы делать, и через memcache писать в базу, вообще не используя SQL (читать тоже можно).

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

VoltDB
Ребята грамотные,

Судя по животрепещущему описанию - не очень они и грамотные.

VoltDB
Да и посчитали сколько такая разработка стоить может - получилось, что не окупится такая штука много лет.

Это общая проблема всех. В мире понаписано столько уже всякой ерунды, что задача даже интеграции этого всего в единый и работоспособный комплекс (компоненты разных вендоров), да еще и поддержка этого всего в работоспособном виде в процессе эксплуатации - это практически нереальная задача.

Мы вот осознали, что проще запилить свое решение почти с нуля, взяв что-то за основу. Просто чтоб иметь возможность контролировать его.

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

Пока решили остановиться на собственном NoSQL решении с использованием движка от LMDB (лучше ничего не нашли, а LMDB код вполне адекватен и управляем, архитектура тоже вполне себе), для критичных по времени реакции OLTP операций (фронтофис), и допилить для него возможность read-only режим через MySQL драйвер, исключительно для некритичных по времени реакции произвольных аналитических отчетов, там посчитать статистику или дать поиграть аналитику с данными (бекофис).

Результаты такой комбинации очень обнадеживающие, хотя пока не ясно, выйдет ли это все за рамки локального проекта (на все про все ушло лишь пару человеко-месяцев, что есть суть пустяк, но вот популяризация в массах может занять раз в 100-200 больше ресурсов на нулевом этапе).

Но вот то что там у вас в VoltDB - это, конечно, полный и феерический бред на текущий момент, мы бы так никогда не поступили.

Начиная от Java как основы - это же надо было так обосраться додуматься до такого, господи. Видно вы там совсем за отраслью не следите, и не видите, куда в реальности привели практически все NoSQL решения, на Java понаписанные (для справки, все спущены в унитаз, в результате попыток эксплуатации, начиная от отказа фейсбука от кассандры и дальше). Причина фатальной ошибки - именно Java, ибо она генетически не способна управляться с гигабайнтыми heap.

На стенде все отлично, доходим до продакшина - залипания серверов на несколько десятков (!) секунд исключительно по вине GC (stop the world syndrom), отказы в обслуживании - в общем Java во всей своей красе.

В сад, в сад, в сад.
8 янв 14, 03:54    [15385439]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
Вячеслав Любомудров
А мне вот, как неспециалисту, совершенно непонятно, как SN можно приложить к тому же банковскому бизнесу, я уже молчу о карточном


Похоже, что понятие Shared-Nothing вызвало немало споров на форуме :) SN - это. вообще-то, термин не имеющий прямого отношения к базам данных и используемый в супер-компьютинге. Все что это значит (упрощенно), это то, что в кластере нет централизованного хранилища (SAN), т.е все данные "размазаны" по всем нодам (как в Хадупе, Вертике). Сам термин к СУБД не относится, и, в контексте наших дискуссий, не означает, что данные в базе "приписаны" клиентам, и что каждый клиент имеет доступ только к свой части данных. Shared-Nothing используется в HPC (High-Performance Computing) уже много лет и проявила себя как архитектура, способная к высокой масштабируемости кластера т.к в таком кластере нет "мест общего пользования" (например, централизованое хранилище) которые могут потенциально оказаться слабым местом системы.

Теперь о VoltDB. Данные поделены между ядрами процессора, а не между приложениями-клиентами. Например, в 3-узловом кластере, состаящем из, скажем, 2x 2.66Ghz Quad-Core Xeon 5550, данные будут распределены между 24 партициями - одна партиция для каждого ядра в кластере.

Клиент ничего не должен знать о деталях конфигурации кластера или базы - с его точки зрения все узлы равны. Все что он знает, это адрес, по которому он может найти базу. Это даже может быть виртуальный адрес аппаратного балансировщика, который следит за физической нагрузкой на каждый узел кластера (CPU, memory usage и.т.д) и решает какой узел наименее нагружен, т.е к какому лучше подосединить клиента (если такая функциональность нужна).

Каждый запрос описан в хранимая процедуре и определяется как отдельная транзакция. Хранимая процедура (т.е. транзакция) коммитается или откатывается целиком, обеспечивая целостность данных.

Во время предварительной компиляции сохраненной процедуры, VoltDB анализирует логику доступа к данным и "привязывает" данные, и их обработку к отдельным узлам кластера. Таким образом, каждый узел кластера содержит уникальный "срез" данных и процесса их обработки.

Во время выполнения запроса, вызовы к сохраненным процедурам передаются в соответствующий узел кластера. Если процедура "single-partitioned" (т.е то есть работает с данными в пределах одной партиции), то ядро выполняет процедуру индивидуально, освобождая остальную часть кластера для параллельной обработки других запросов. Если процедура "multi-partitioned", т.е требует данных из нескольких партиций, то одно ядро координирует необходимую работу с другими ядрами по всему кластеру, затем собирает результаты и завершает задачу. Эта координация делает "multi-partitioned" транзакции обычно медленнее, чем "single-partitioned". Тем не менее, параллельное исполнение запросов обеспечивает максимальную пропускную способность.
8 янв 14, 04:23    [15385449]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
Капитан очевидность на проводе
VoltDB
Другими словами, с точки зрения бизнеса, может оказаться, что разработка такого приложения - "игра, не стоящая свечь". Если же Ваше предложение сделано в контексте NoSQL, то это совсем другое дело - в этом случае, боюсь, выбор решений небольшой т.к такие системы по определению не поддерживают структурных языков запросов.

Решение с шардингом (менеджер пулов-балансировщик нагрузки) одинаково применимо и к SQL, и к NoSQL решениям, это раз.
Два - NoSQL решения также предусматривают структурые языки запросов, ознакомьтесь для начала с Cassanrda и MongoDB.
В т.ч. возможны и кросснодовые джойны, хотя это в общем случае еще та глупость.

Кроме того, никто не мешает к любой NoSQL базе ходить через MySQL - все что нужно, это понаписать свой движок, взяв пример движка CSV как основу (там порог вхождения очень низкий).

VoltDB
Но в этом случае, предмет дискуссии, наверное, сводился бы к совсем другому, а именно, "А что лучше, SQL или NoSQL?".

Не лучше ни то, ни другое. NoSQL - отличное решения для задач класса OLTP, SQL - это сейчас больше удел исключительно DWH.
Делать на SQL высоконагруженную OLTP систему (более 5 операций в секунду) - это признак полной неадекватности разработчиков.

При этом оптимальным является решение которое комбинирует оба варианта, т.е. одна и та-же физическая база данных доступна в разных режимах разными средствами. Для OLTP ходим в нее напрямую как в NoSQL (с гарантированным временем реакции, близком к realtime), для отчетов и аналитики - через MySQL плагин какой (с минимальным приоритетом процессов чтения этих данных).

К примеру в MySQL такое решение уже существует http://dev.mysql.com/doc/refman/5.6/en/innodb-memcached-intro.html .
Т.е. можем и SQL запросы делать, и через memcache писать в базу, вообще не используя SQL (читать тоже можно).

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

VoltDB
Ребята грамотные,

Судя по животрепещущему описанию - не очень они и грамотные.

VoltDB
Да и посчитали сколько такая разработка стоить может - получилось, что не окупится такая штука много лет.

Это общая проблема всех. В мире понаписано столько уже всякой ерунды, что задача даже интеграции этого всего в единый и работоспособный комплекс (компоненты разных вендоров), да еще и поддержка этого всего в работоспособном виде в процессе эксплуатации - это практически нереальная задача.

Мы вот осознали, что проще запилить свое решение почти с нуля, взяв что-то за основу. Просто чтоб иметь возможность контролировать его.

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

Пока решили остановиться на собственном NoSQL решении с использованием движка от LMDB (лучше ничего не нашли, а LMDB код вполне адекватен и управляем, архитектура тоже вполне себе), для критичных по времени реакции OLTP операций (фронтофис), и допилить для него возможность read-only режим через MySQL драйвер, исключительно для некритичных по времени реакции произвольных аналитических отчетов, там посчитать статистику или дать поиграть аналитику с данными (бекофис).

Результаты такой комбинации очень обнадеживающие, хотя пока не ясно, выйдет ли это все за рамки локального проекта (на все про все ушло лишь пару человеко-месяцев, что есть суть пустяк, но вот популяризация в массах может занять раз в 100-200 больше ресурсов на нулевом этапе).

Но вот то что там у вас в VoltDB - это, конечно, полный и феерический бред на текущий момент, мы бы так никогда не поступили.

Начиная от Java как основы - это же надо было так обосраться додуматься до такого, господи. Видно вы там совсем за отраслью не следите, и не видите, куда в реальности привели практически все NoSQL решения, на Java понаписанные (для справки, все спущены в унитаз, в результате попыток эксплуатации, начиная от отказа фейсбука от кассандры и дальше). Причина фатальной ошибки - именно Java, ибо она генетически не способна управляться с гигабайнтыми heap.

На стенде все отлично, доходим до продакшина - залипания серверов на несколько десятков (!) секунд исключительно по вине GC (stop the world syndrom), отказы в обслуживании - в общем Java во всей своей красе.

В сад, в сад, в сад.


У почему Вы решили, что Volt весь на Java написан? У нас системный код на С/С++, Java только для кода высокого уровня.

Кстати, успехов Вам с разработкой своего собственного движка (искренне!). Когда будет что-нибудь работающее, свяжитесь со мной - я бы с удовольствием попробовал.
8 янв 14, 04:37    [15385452]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
VoltDB
Капитан очевидность на проводе
пропущено...

Решение с шардингом (менеджер пулов-балансировщик нагрузки) одинаково применимо и к SQL, и к NoSQL решениям, это раз.
Два - NoSQL решения также предусматривают структурые языки запросов, ознакомьтесь для начала с Cassanrda и MongoDB.
В т.ч. возможны и кросснодовые джойны, хотя это в общем случае еще та глупость.

Кроме того, никто не мешает к любой NoSQL базе ходить через MySQL - все что нужно, это понаписать свой движок, взяв пример движка CSV как основу (там порог вхождения очень низкий).

пропущено...

Не лучше ни то, ни другое. NoSQL - отличное решения для задач класса OLTP, SQL - это сейчас больше удел исключительно DWH.
Делать на SQL высоконагруженную OLTP систему (более 5 операций в секунду) - это признак полной неадекватности разработчиков.

При этом оптимальным является решение которое комбинирует оба варианта, т.е. одна и та-же физическая база данных доступна в разных режимах разными средствами. Для OLTP ходим в нее напрямую как в NoSQL (с гарантированным временем реакции, близком к realtime), для отчетов и аналитики - через MySQL плагин какой (с минимальным приоритетом процессов чтения этих данных).

К примеру в MySQL такое решение уже существует http://dev.mysql.com/doc/refman/5.6/en/innodb-memcached-intro.html .
Т.е. можем и SQL запросы делать, и через memcache писать в базу, вообще не используя SQL (читать тоже можно).

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

пропущено...

Судя по животрепещущему описанию - не очень они и грамотные.

пропущено...

Это общая проблема всех. В мире понаписано столько уже всякой ерунды, что задача даже интеграции этого всего в единый и работоспособный комплекс (компоненты разных вендоров), да еще и поддержка этого всего в работоспособном виде в процессе эксплуатации - это практически нереальная задача.

Мы вот осознали, что проще запилить свое решение почти с нуля, взяв что-то за основу. Просто чтоб иметь возможность контролировать его.

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

Пока решили остановиться на собственном NoSQL решении с использованием движка от LMDB (лучше ничего не нашли, а LMDB код вполне адекватен и управляем, архитектура тоже вполне себе), для критичных по времени реакции OLTP операций (фронтофис), и допилить для него возможность read-only режим через MySQL драйвер, исключительно для некритичных по времени реакции произвольных аналитических отчетов, там посчитать статистику или дать поиграть аналитику с данными (бекофис).

Результаты такой комбинации очень обнадеживающие, хотя пока не ясно, выйдет ли это все за рамки локального проекта (на все про все ушло лишь пару человеко-месяцев, что есть суть пустяк, но вот популяризация в массах может занять раз в 100-200 больше ресурсов на нулевом этапе).

Но вот то что там у вас в VoltDB - это, конечно, полный и феерический бред на текущий момент, мы бы так никогда не поступили.

Начиная от Java как основы - это же надо было так обосраться додуматься до такого, господи. Видно вы там совсем за отраслью не следите, и не видите, куда в реальности привели практически все NoSQL решения, на Java понаписанные (для справки, все спущены в унитаз, в результате попыток эксплуатации, начиная от отказа фейсбука от кассандры и дальше). Причина фатальной ошибки - именно Java, ибо она генетически не способна управляться с гигабайнтыми heap.

На стенде все отлично, доходим до продакшина - залипания серверов на несколько десятков (!) секунд исключительно по вине GC (stop the world syndrom), отказы в обслуживании - в общем Java во всей своей красе.

В сад, в сад, в сад.


У почему Вы решили, что Volt весь на Java написан? У нас системный код на С/С++, Java только для кода высокого уровня.

Кстати, успехов Вам с разработкой своего собственного движка (искренне!). Когда будет что-нибудь работающее, свяжитесь со мной - я бы с удовольствием попробовал.


Да, насчет систем которые поддерживают SQL и NoSQL, мы - одна из них и поддерживаем и key-value и JSON-документы (это к разговору о MongoDB). У нас даже тест опубликован о пропускной способности для key-value системы в 1 миллион транзакций в секунду
8 янв 14, 04:49    [15385453]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
капитан недоочевидность
Guest
Капитан очевидность на проводе
Но вот то что там у вас в VoltDB - это, конечно, полный и феерический бред на текущий момент, мы бы так никогда не поступили.

вы - это кто?
8 янв 14, 05:31    [15385455]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Капитан очевидность на проводе
Guest
VoltDB
У почему Вы решили, что Volt весь на Java написан? У нас системный код на С/С++, Java только для кода высокого уровня.


Потому что у вас отсутствуют API на C/C++ в документации и примерах. В любом случае - я готов рассматривать продукт как продут только если Java там как неключевая и полностью отключаемая опция (как в Oracle RDBMS). Даже если вы сделали свой собственный off-heap - это не меняет абсолютно ничего, Java с ее GC менопаузами как ключевой компонент ядра - это откровенный бред.


VoltDB
Кстати, успехов Вам с разработкой своего собственного движка (искренне!). Когда будет что-нибудь работающее, свяжитесь со мной - я бы с удовольствием попробовал.


Движок этот лишь часть системы, у нас нет задачи делать его продуктом. Появится лишь в составе прикладного framework (что-то вроде node.С - да да, прикладной код можно писать на С/С++), но это планы только на 2015-й год.

База данных это не самоцель, для программистов нужно законченное решение, позволяющее выдавать html/json клиенту.
Просто очередной библиотекой для БД сейчас уже никого не впечатлишь.
8 янв 14, 08:20    [15385490]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3909
Капитан очевидность на проводе
Даже если вы сделали свой собственный off-heap - это не меняет абсолютно ничего, Java с ее GC менопаузами как ключевой компонент ядра - это откровенный бред.

https://github.com/VoltDB/voltdb/tree/master/src/ee
8 янв 14, 09:51    [15385515]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
Капитан очевидность на проводе
VoltDB
У почему Вы решили, что Volt весь на Java написан? У нас системный код на С/С++, Java только для кода высокого уровня.


Потому что у вас отсутствуют API на C/C++ в документации и примерах. В любом случае - я готов рассматривать продукт как продут только если Java там как неключевая и полностью отключаемая опция (как в Oracle RDBMS). Даже если вы сделали свой собственный off-heap - это не меняет абсолютно ничего, Java с ее GC менопаузами как ключевой компонент ядра - это откровенный бред.


VoltDB
Кстати, успехов Вам с разработкой своего собственного движка (искренне!). Когда будет что-нибудь работающее, свяжитесь со мной - я бы с удовольствием попробовал.


Движок этот лишь часть системы, у нас нет задачи делать его продуктом. Появится лишь в составе прикладного framework (что-то вроде node.С - да да, прикладной код можно писать на С/С++), но это планы только на 2015-й год.

База данных это не самоцель, для программистов нужно законченное решение, позволяющее выдавать html/json клиенту.
Просто очередной библиотекой для БД сейчас уже никого не впечатлишь.


Звучит серьезно... Это Вы один такую framework разрабатываете или с кем-то еще стартап делаете, или же организация какая спорнсирует?
8 янв 14, 10:38    [15385548]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
VoltDB

Во время предварительной компиляции сохраненной процедуры, VoltDB анализирует логику доступа к данным и "привязывает" данные, и их обработку к отдельным узлам кластера.

Т.е. при переконфигурации кластера надо перекомнилировать весь хранимый код?
8 янв 14, 14:02    [15386113]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
essbase.ru
Member

Откуда: http://essbase.ru/about
Сообщений: 1407
VoltDB
INSERT, SELECT, UPDATE

А как со встроенным языком ?
Есть ли более - меннее продвинтый язык структурного (объектного) программирования?

ЕР
8 янв 14, 17:26    [15386758]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
Я и ёжик
VoltDB
Во время предварительной компиляции сохраненной процедуры, VoltDB анализирует логику доступа к данным и "привязывает" данные, и их обработку к отдельным узлам кластера.

Т.е. при переконфигурации кластера надо перекомнилировать весь хранимый код?


Иноформация о конфигурации кластера и о БД-схеме хранится в компилированниом файле-каталоге. Каталог является единственным местом которое пользователь изменяет и перекомпилирует при внесении изменений в конфигурацию кластера - все остальное происходит автоматически
8 янв 14, 20:03    [15387275]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
Я и ёжик
VoltDB
Во время предварительной компиляции сохраненной процедуры, VoltDB анализирует логику доступа к данным и "привязывает" данные, и их обработку к отдельным узлам кластера.

Т.е. при переконфигурации кластера надо перекомнилировать весь хранимый код?


$ voltdb compile my_scema.sql
8 янв 14, 20:08    [15387290]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
essbase.ru
Member

Откуда: http://essbase.ru/about
Сообщений: 1407
VoltDB
тогда репартицирование не нужно.

Есть ли менеджеры, которые собирают статистику запросов и предлагают новые партиции ?
8 янв 14, 20:27    [15387322]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
essbase.ru
Member

Откуда: http://essbase.ru/about
Сообщений: 1407
VoltDB,
Что нужно делать когда по каким то причинам нужны аналитические запросы к БД , SUM or AVG по всей таблице ? Перекачивать данные в "классическую" БД ?


ЕР
8 янв 14, 21:04    [15387398]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
essbase.ru
VoltDB
INSERT, SELECT, UPDATE

А как со встроенным языком ?
Есть ли более - меннее продвинтый язык структурного (объектного) программирования?

ЕР
Клиентское приложение может посылать запросы двух типов: вызов сохраненной процедуры или SQL запрос. В обоих случаях, клиентское приложение может делать все традиционные операции с возвращенными скаляром или набором строк. На стороне приложения-клиента, поддерживаются многоие популярные технолгоии, включая JAVA, С++, C#, PhP и др. Включена консоль sqlcmd, позволяющая производить SQL запросы к данным из командной строки.

В части языка программирования: SQL для ad-hoc запросов или JAVA+SQL для сохраненных процедур

Пример сохраненной процедуры (обратите внимание, что это JAVA-код, исполняемый на стороне СУБД, а не клиентского приложения):


import org.voltdb.*;

public class Procedure-name extends VoltProcedure {

                 // Declare SQL statements ...

    public datatype run ( arguments ) throws VoltAbortException {


                // Body of the Stored Procedure ...


    }
}


Более подробную информацию можно найти в "Кратком Справочнике По Использованию" здесь:

http://voltdb.com/docs/UsingVoltDB/ChapAppDesign.php

http://voltdb.com/docs/UsingVoltDB/DesignProc.php

Для того, что бы послать запрос к сохраненной процедуре, сначала клиент должен подключиться к БД (важно отметить, что в примеры ниже - это код, исполняющийся на стороне приложения. Хотя примеры приведены для JAVA, другие популярных технолгоии приложений-клиентов тоже поддерживаются, включая С++, C#, PhP и другие):

org.voltdb.client.Client client = null;
ClientConfig config = null;
try {
       config = new ClientConfig("advent","xyzzy");
       client = ClientFactory.createClient(config);
       client.createConnection("myserver.xyz.net");
} catch (java.io.IOException e) {
       e.printStackTrace();
       System.exit(-1);
}

client.createConnection("myserver.xyz.net",21211);


После того,как соединение с БД установленно, клиент может сделать вызов сохраненной процедуры синхронно:

VoltTable[] results;
try { results = client.callProcedure("LookupFlight", 
                                     origin, 
                                     dest, 
                                     departtime).getResults();
} catch (Exception e) {
     e.printStackTrace();
     System.exit(-1);
}


...или, если нужно, асинхронно:

client.callProcedure(new MyCallback(), `
                     "NewCustomer",
                     firstname, 
                     lastname, 
                     custID};


Дополнительную информацию по разработке клиентских приложений, можно найти здесь:

http://voltdb.com/docs/UsingVoltDB/DesignAppLogic.php
8 янв 14, 21:22    [15387452]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
essbase.ru
VoltDB,
Что нужно делать когда по каким то причинам нужны аналитические запросы к БД , SUM or AVG по всей таблице ? Перекачивать данные в "классическую" БД ?


ЕР


Нет, не нужно. Система поддерживает аналитические запросы. Я бы даже больше сказал, так как данные находятся в памяти, сканирование таблиц (или больших участков таблиц) при выполнении агрегатных запросов происходит быстрее чем в дисковых OLTP системах.
8 янв 14, 21:30    [15387480]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
essbase.ru
Member

Откуда: http://essbase.ru/about
Сообщений: 1407
VoltDB
$ voltdb compile my_scema.sql


Подскажите пж. что уже реализовано из этого списка ?

http://citforum.ru/news/23876/

Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка СУБД);
Набор инструментов для мониторинга кластера;
Интерфейс для доступа клиентов с использованием формата JSON;
Увеличение производительности транзакции для выполнения которых необходимо привлечение данных из нескольких разделов;
Расширение поддерживаемого синтаксиса SQL (сейчас поддерживаются только простейшие операции);
Возможность автоматической замены сбойного узла на лету;
Расширение возможностей по экспорту данных из БД;
Поддержка WAN-репликации между территориально разделенными узлами;
Возможность подключения новых узлов к кластеру на лету и вывод узлов без остановки кластера.
8 янв 14, 21:37    [15387504]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
essbase.ru
VoltDB
тогда репартицирование не нужно.

Есть ли менеджеры, которые собирают статистику запросов и предлагают новые партиции ?


Если Вы имеете ввиду простую статистику исполнение запросов (т.к запрос А был исполнен такое-то количество раз, а запрос В - такое-то), то эта информация легко доступна. Если же Вы имеете ввиду статистическую гистограмму распределения данных в таблице, то такой механизм, насколько мне известно, не поддержан.
8 янв 14, 21:43    [15387516]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
essbase.ru
VoltDB
$ voltdb compile my_scema.sql


Подскажите пж. что уже реализовано из этого списка ?

http://citforum.ru/news/23876/

Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка СУБД);
Набор инструментов для мониторинга кластера;
Интерфейс для доступа клиентов с использованием формата JSON;
Увеличение производительности транзакции для выполнения которых необходимо привлечение данных из нескольких разделов;
Расширение поддерживаемого синтаксиса SQL (сейчас поддерживаются только простейшие операции);
Возможность автоматической замены сбойного узла на лету;
Расширение возможностей по экспорту данных из БД;
Поддержка WAN-репликации между территориально разделенными узлами;
Возможность подключения новых узлов к кластеру на лету и вывод узлов без остановки кластера.


Это "лист пожеланий" для одной из самых первых версий системы 1.х, составленный, наверное, где-то в 2009 году. Вся указанная функциональность (и гораздо больше) давно реализована и используется - ведь на пороге версия 4.0
8 янв 14, 21:51    [15387538]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
essbase.ru
Member

Откуда: http://essbase.ru/about
Сообщений: 1407
VoltDB
- ведь на пороге версия 4.0

а как дела обстоят с апгрейдом бинарников ? Данные переползают между релизами безболенено ? Патчи ставятся с возможностью отката ?

Что бы забэкапить систему на холодную - нужно остановить весь кластер ? (вообще где можно почитать о бэкапе ) ?

Если я задумаю DR и захочу дублирующий кластер , есть ли шанс это сделать силами системы ?
8 янв 14, 22:02    [15387567]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
essbase.ru
VoltDB
- ведь на пороге версия 4.0


а как дела обстоят с апгрейдом бинарников ? Данные переползают между релизами безболенено ? Патчи ставятся с возможностью отката ?
Да. Детали можно найти здесь: http://voltdb.com/docs/MgtGuide/UpdateDBChap.php

essbase.ru
Что бы забэкапить систему на холодную - нужно остановить весь кластер ?

Нет, останавливать кластер не нужно.

автор
(вообще где можно почитать о бэкапе )?

Вся документация на которую я делаю ссылки находится в свободном доступе и может быть Вами загружена здесь:

http://voltdb.com/dev-center/documentation/

essbase.ru
]Если я задумаю DR и захочу дублирующий кластер , есть ли шанс это сделать силами системы ?
Конечно, реплицирование в запасной кластер полностью поддержано. Можете даже реплицировать в запасной дата центр, если нужно
8 янв 14, 22:46    [15387691]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9   вперед  Ctrl      все
Все форумы / Oracle Ответить