Наверх ▲

Growing in the Wild. The story by CUBRID Database Developers

Eugene Stoyanovici Eugene Stoyanovici Senior Software Engineer at CUBRID. Эсен Сагынов (Esen Sagynov) Эсен Сагынов (Esen Sagynov) Разработчик в NHN - крупнейшей IT-компании Южной Кореи.

Есен Сагинов (Esen Sagynov), CUBRID Project Manager (записано со слов переводчика):

– Здравствуйте. Сегодня мы будем говорить на английском. Я надеюсь, вы понимаете по-английски. Тот, кто не понимает, может слушать перевод.

Меня зовут Есен Сагинов. Я занимаюсь проектом CUBRID и являюсь менеджером по связям с общественностью. Занимаюсь всякими аспектами взаимодействия с пользователями, средствами коммуникации, которые нужны пользователям.

В CUBRID у нас три команды. Одна находится в Корее (примерно треть персонала там работает), вторая в Китае. Первая команда – 30 человек. В Китае – 15 человек. Третья команда в Румынии – около 10-ти человек там работает.

Юджин – разработчик. Он работает над базовой платформой CUBRID. Пожалуйста, представьтесь.

 

Юджин Стояновичи (Eugene Stoyanovici), Senior Software Engineer at CUBRID (записано со слов переводчика):

– Здравствуйте. Я Юджин, член команды CUBRID, занимаюсь проектами совместимости и повышения производительности в рамках CUBRID.

Есен Сагинов (записано со слов переводчика): Когда мы получили от RIT++ приглашение участвовать в конференции, конечно, мы были очень рады. Но сразу было видно, что приглашение отличается от того, что мы получали от имени других конференций.

Было ясно, что о CUBRID организаторы практически ничего не знают. Нас просили объяснить всему российскому сообществу разработчиков, как мы разработали эту платформу, зачем мы ее разработали, почему мы не пользовались уже существующими решениям (например, Oracle, SQL и так далее). Зачем надо было разрабатывать CUBRID. Почему мы не делали какие-то совместные разработки с другими разработками, сиквел решения.

Сегодня мы будем говорить именно об этом и расскажем, почему затеяли собственную разработку.

Сначала хочу показать несколько слайдов о CUBRID.

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

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

"NHN" – это ведущая IT-компания в Корее и 13-я по величине в мире. Я думаю, о нашей компании вы слышали. Штаб-квартира находится в Южной Корее, также есть подразделения в Соединенных Штатах, Китае и Японии.

Только в Корее "NHN" имеет около 150 web-сервисов (очень крупных и не очень крупных). Некоторые сравнимы по размеру с Яндексом – мы можем здесь сопоставить наши усилия с тем, что делают коллеги. В целом, мы имеем около 30 тысяч web-сервисов и 5000 разработчиков.

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

Мы пользуемся уже существующими решениями (Oracle, Microsoft SQL Server) для игровых решений, для биллинговых систем. Мы действительно этим пользуемся, нам нравятся эти инструменты. SQL – это здорово! Но не до конца соответствует всем нашим потребностям: немного не хватает инструментов.

Почему мы занялись разработкой CUBRID. Есть существующие решения – в основном, это коммерческие решения: мы покупаем лицензии на них. У нас есть web-сервисы, сервисы баз данных – и большое количество денег тратится на лицензии. Несколько миллионов долларов уходит только на приобретение лицензий и их кастомизацию. Это один аспект.

Важен также технический аспект. У нас в компании есть крупные web-сервисы, и необходимо оптимизировать базы данных. Иногда необходимо разбивать на страницы существующие базы данных.

Есть некоторая поддержка со стороны Oracle в их решениях. Но у них такая политика: в случае возникновения необходимости, мы сначала должны послать отчет в Корею (в наш основной офис) – потом это отправляется в США – и они отвечают нам. На все это уходит время.

Но бывают критически важные ситуации, когда надо действовать очень быстро. Мы не можем позволить себе тратить так много времени на все это. А такие переговоры иногда занимают до шести месяцев! Мы не можем так долго ждать.

Поэтому приходится думать о том, как это все отладить самим.

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

Мы подумали: это может быть решение с открытым кодом, либо мы можем начинать с чего-то совершенно нового. Конечно, мог быть применен Forking (Forking применительно к MySQL или другим решениям с открытым кодом). Но надо было, прежде всего, разобраться в философии (почему именно так, а не этак была создана та или иная архитектура), чтобы можно было этой архитектурой пользоваться.

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

На это тоже необходимо время – но мы подумали, что в ходе такой разработки еще многому научимся.

При таком подходе есть много преимуществ.

С одной стороны, вы не платите за различные лицензии, за кастомизацию и так далее. С другой стороны, вы приобретаете нечто более ценное: вы получаете решение, которое соответствует вашим базовым технологическим возможностям и инструментам. Мы надеялись, что разрабатывая наше собственное решение, мы еще многому научимся – научимся разрабатывать такие решения, которые можно будет повторно использовать.

На базе CUBRID мы разработали много таких решений.

×          Используя облачные вычисления, разработали систему СУБД, подобную Amazon.

×          У нас есть крупная мониторинговая система на уровне предприятия, которая обрабатывает тысячи различных записей.

×          Ввели нашу собственную систему файлов на основе CUBRID.

И так далее.

Есть большое количество технологических решений повторного использования, которые мы разработали благодаря тому, что 6 лет назад разработали CUBRID. Это было стратегическое решение – начать разрабатывать базу данных CUBRID.

Когда мы приняли это решение, мы поставили 4 основные задачи.

a)     Поскольку у нас было много web-сервисов, мы обратили особое внимание на стабильность. Мы хотели получить продукт, который обеспечит достаточную стабильность. С тем, чтобы сервис-менеджеры захотели переключиться на CUBRID с тех решений, которые у них есть.

b)    Производительность. Какая производительность будет приемлемой. Надо было с самого начала разработать такое решение, которое даст достаточный и приемлемый уровень производительности. Не обязательно выше того, что имеется – но приемлемый. Мы это тоже принимали во внимание с самого начала.

c)     Масштабируемость. У нас очень много разных сервисов, и надо, чтобы они были масштабируемы. Надо было разрабатывать такой продукт, который бы легко масштабировался.

Об этом я расскажу несколько позже.

Что касается производительности: Юджин является нашим экспертом по производительности. Он дальше продолжит нашу презентацию.

Юджин Стояновичи (записано со слов переводчика): Производительность – одна из основных целей нашей системы, но это больше, чем цель. Мы хотим, чтобы производительность была фиксированной, измеряемой и давала результаты.

Мы работаем с пятилетними картами, в которых определяются основные вехи, циклы релизов. Эти вехи у нас обозначаются в соответствии с тем, что собирается делать пользователь с CUBRID сегодня и в ближайшем будущем.

Что касается производительности проекта, то у нас две цели. Во-первых, улучшить производительность: мы хотим, чтобы CUBRID была быстрой. Во-вторых, разумность – чтобы все, что мы делаем в CUBRID, встраивалась бы в общую картину.

Рассмотрим следующий пример. Это фичер – покрывающие индексы. Просто иной подход рассмотрения индексов и подхода к индексам.

Обычно мы сначала обращаемся к индексу, чтобы найти то, что ищем. Оно располагается в таблице. Вы видите два этапа: сначала обращение к индексу, потом поиск в таблице.

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

Когда мы смотрим Этап 1 (Phase 1), это конкретизирует функцию выбора. Дальше мы идем на Этап 3 (Phase 3). Очень важно, что переход на Этап 3 (Phase 3) осуществляется автоматически.

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

Это диаграмма показывает, по сути, таблицу деятельности, производительности. Синяя линяя (это QPS CUBRID HA) – основные показатели предсказания \прогноза\. Вы может предсказать, какие данные будут через три месяца, через шесть месяцев или год. Естественно, нужно чтобы данные были стабильными. Если не будет стабильности – не будет работать эта система.

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

 

Есен Сагинов (записано со слов переводчика): Есть очень важный момент в этом графике. Хочу вам его показать. Мы используем массивы данных, чтобы выполнять услуги. Для этого мы используем MySQL: малые услуги выполняются с помощью MySQL.

MySQL может работать гораздо быстрее, чем CUBRID, и мы знаем об этом – нам это хорошо известно. MySQL гораздо лучше работает в небольших масштабах, при выполнения каких-то незначительных функций [вар. – не слишком объемных задач]. Но функция MySQL не работает на крупных проектах.

Падение красной линии на графике показывает именно это.

С помощью CUBRID мы хотим обеспечить предсказуемость для наших web-сервисов. Мы хотим показать, что из себя представляет производительность программы, каким образом можно увеличивать показатели деятельности. Именно этот фактор важен для нас.

Второй критерий, на котором мы акцентируем внимание – масштабируемость.

На этом слайде мы выписали вопросы. Сервис-менеджер по критическим(?) процессам(?) задает эти вопросы: что использовать, независимо от того, будет это синхронизированный или асинхронный подход. Какое будет выбрано решение: балансировка загрузки либо решение третьей стороной. Что относительно сбоев – кто будет этим руководить?

Менеджеры web-сервисов как раз и задают эти вопросы. Это те моменты, которые важны для клиентов. Клиенты сами задают нам все необходимые параметры. И есть решения, которые дает нам CUBRID – это бесперебойная услуга 24 часа в сутки / 7 дней в неделю.

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

Мы разрабатываем репликацию. В 2008-м году был первый выпуск, основанный (как я говорил) на MySQL. Но наши клиенты просят нас: если этого не достаточно (услуг для 24/7 service uptime), как еще мы можем увеличить качество CUBRID. Сначала это было основано на Linux(?).

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

Мы решили разработать собственную технологию.

Это исконная технология CUBRID, очень точная, которая имеет начало и конец. Разрешимость через 2 секунды, через 3 секунды – очень точная фиксация данных, очень предсказуемые (прогнозируемые) действия. Это то, как мы разработали нашу систему CUBRID после "хат битс" (40:14).

Мы были очень счастливы! Мы были рады тому, что на третьем этапе предоставили нашим клиентам три мода режима брока(?).

Если мы посмотрим на эту услугу брокера, мы увидим, что есть архитектура, которая включает в себя сервер и брокера. Акцент делается на брокера. Это может быть режим read/write (писать и читать), это главный сервер. Могут быть услуги по сохранению и услуги по репликации.

DBS имеет некоторые изменения в схеме. В отношении базы данных обычно они хотят, чтобы мы улучшили здесь услуги. Но можно конфигурировать режим брокера CUBRID таким образом, чтобы была услуга только чтения. Только выбор информации будет предоставляться и не будет никакой функции написания (записи).

Есть специальные изменения конфигурации. Это очень легко! Просто изменить переключение для брокера. Это мы как раз и сделали на Этапе 2 в CUBRID.

Далее.

Мы, конечно, улучшили стабильность, выполнимость поставленных задач. Наши клиенты могут использовать CUBRID адаптацию с помощью HA репликации. Это дает нам возможность осуществлять мониторинг. Администрация CUBRID обладает всем необходимым набором инструментов для этого.

Возможности репликации – это больше не услуга slave'ера, но вы можете добавить репликацию. Она будет не в рамках HA, но может быть все-таки востребована как функция репликации HA.

Фактически что мы недавно сделали? Мы улучшили показатели деятельности HA. Предстоящим летом мы сделаем…

Мы ориентируемся на клиентов. Они говорят: "Конечно, это неизбежно, но когда умирает ваш главный сервер – что тогда будет происходить?"

Когда главный сервер умирает, эту поддерживающую функцию должен обеспечивать сервер slave. Очень сложные вопросы здесь возникают. Чтобы сохранить данные главного сервера (это несколько терабайт, десятки терабайт данных) – уходит 10 часов!

Наши клиенты говорят: "Это хорошо, что вы можете оживить систему. Но нам не нравится время, за которое вы это делаете – порядка 10-ти часов. Можно ли настроить дополнительные инструменты, которые могли бы оживить сервер slave очень быстро, и мы могли бы возродить данные?"

Автоматически с помощью DBA можно было бы это сделать. На практике вручную можно это сделать с помощью набора определенных команд доступа к базе данных. Но теперь есть набор инструментов, которые позволяют это сделать. Это очень удобно можно реализовать.

Мы двигаемся от основного компонента с помощью CUBRID. Мы работаем в основном с теми вопросами, которые интересуют наших клиентов. Есть два размера(?), каким образом мы используем репликацию, и репликация требует теперь гораздо меньше времени.

Мы можем искать другие опции, другие решения – и этого не могут сделать другие приложения (например, Oracle).

CUBRID все делает, по сути говоря, "в одном пакете". Наши базы данных акцентированы на конкретных моментах. Не надо приглашать экспертов из других отделов или разработчика приложения. Мы все делаем в одном пакете, благодаря нашей системе, которая настраивается.

Есть HA, который является радикальным. Мы должны сказать, что это действительно флагман в нашей системе CUBRID.

В CUBRID HA несколько конфигураций, которые могут быть применены к базе данных. Это может быть один к одному master/slave. Это может быть также услуга репликации от master к slave. Мы можем улучшить взаимосвязь между главным сервером и slave'ом. Если очень много разных функций идет со стороны master, можно этот поток уменьшить.

Нам нужно идти к третьему решению, которое может нам помочь. Мы уже здесь говорили о CUBRID HA в прошлом году. Если вы заинтересовались, можете посмотреть презентацию прошлого года.

CUBRID HA действительно дает нам большие преимущества. Это бесперебойная эксплуатация, это автосистема настройки для преодоления сбоев – осуществляется предсказуемое действие для выхода из ситуации провала. Также создается система синхронного действия брокеров. Очень хорошая конфигурация для различных master/slave.

CUBRID HA хорошо известна в компаниях. Есть несколько примеров того, как в начал мы начали заниматься CUBRID. Собственно, это одна из услуг, которую мы имели с несколькими терабайтами информации. 16 операция между master и slave. Эти серверы взаимодействовали: 16 master/slave серверов и одни архивный сервер. Мы постоянно производили репликацию данных CUBRID. MSSQL и CUBRID. Всем понравился CUBRID. Майкрософт использовал MSSQL.

Другая программа, про которую можно сказать – очень удачный кейс со стороны Oracle. У нас было 40 общих серверов. Мы ввели около 40 терабайт данных в базу данных – это было резкое изменение характеристик для производительности серверов. Такая система мониторинга действительно давала много денег. Миллионы долларов дохода! Это огромные доходы для нас.

Я думаю, что можно предсказать огромные преимущества HA и еще много преимуществ, потому что мы можем хорошее сбалансированное отношение выработать, автоматическую балансировку. Это то, что касается чтения данных.

А что касается записи, на сегодняшний день у нас нет баланса между написанием и чтением в кластерном (неразборчиво, 49:59).

Наши провайдеры web-сервисов продолжают спрашивать: "Действительно, нам нравятся ваши функции, но что делать с этой проблемой?" В прошлом году мы нашли новое решение для базы данных – сегментирование. Этим летом были поставлены вопросы относительно сегментирования. Как будет происходить деление между базами банных, в рамках одной базы данных. А также как это деление будет происходить между  множественными данными в рамках базы данных.

Наша компания сейчас использует dbday(?) в базе данных с необходимым брокером CUBRID, который конфигурируется с помощью брокера.

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

В такой среде мы работаем.

CUBRID может быть очень надежным, достоверным источником для работы с огромной базой данных.

Это характерно только для CUBRID. Это решение есть только у нас. Ни у кого таких решений больше нет.

С самого начала мы использовали просмотровые функции и видели, что не было разработчиков приложений на этом этапе.

Что они делают? Они могут нам предоставить базы данных, стратегию для сегментирования. Есть библиотека, чтобы генерировать эти данные HA.

Собственно, это стратегическая цель. Когда они входят в базу данных… Это то, что им нужно сделать – войти в базу данных и провести изменения с метаданными, которые там записаны. Брокерская система позволяет это сделать, и даже более того.

На первом этапе мы все закончили, относительно этих функций сегментирования, чтобы дать полную поддержку самому сегментированию. Но то, что идет у нас – это лимитация нашей задачи. Сегментация обеспечивает нам динамичную схему. Имеющаяся версия DBS системы управления базами данных может эффективно работать с имеющимися данными.

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

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

Очень важный момент, о котором мы сейчас поговорим (важный для сервис-менеджеров, а не сервис-разработчиков) – это простота использования.

Сервис менеджеры часто говорят: "Мы будем развертывать CUBRID. Но у нас есть десятки терабайт данных – как нам это все мигрировать?" Необходимо иметь достаточно инструментов и средств, чтобы это все упростить.

Прежде всего, мы начали с совместимости SQL и API. С точки зрения разработчика, это очень важно. Мы начали с инструментов Oracle и добавили средства поддержки. Сейчас в новой версии CUBRID обеспечивается поддержка 90% совместимости с MySQL. Это очень хороший результат.

В следующей версии основной акцент будет делаться на бизнес-аналитику, биллинговые системы, системы закупок. Там используются, в основном, Oraсle-инструменты, мы будем поддерживать Oracle sequel(сиквел?). Это уже в следующем выпуске.

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

Но это подходит не для всех. Это подходит для тех сервисов, где 300-400 экземпляров баз данных, и надо производить мониторинг их всех. То есть, это большие сервисы.

Мы составили такой план (или "дорожную карту") для новой версии CUBRID. Первая будет выпущена летом этого года. Здесь будет повышена производительность, значимые внутренние возможности, возможности по внедрению и повышению производительности.

Также в будущем мы планируем выпуск легкой версии (light) CUDRID. Она будет обеспечивать все необходимые средства по управлению базами данных и хранению данных. Но не будет включать некоторые инструменты (не нужные небольшим базам данных).

Это, конечно, уже вопрос будущего CUDRID.

Итак, какие уроки мы вынесли на данный момент как разработчики такой новой революционной системы.

Оказалось, чрезвычайно трудно изменить привычки пользователя. Даже мы в нашей компании "NHN", которая разрабатывала CUDRID, с трудом перестраивались на нее.

Были разработчики и пользователи, которые привыкли пользоваться другими инструментами. Они были не готовы переходить на CUDRID. Но любое новое решение на рынке обычно имеет определенные сложности, связанные с изменением поведения пользователя (потребителя) и новым отношением к продукту.

Но мы нашли для этого новое решение. Решение, которое необходимо поддерживать.

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

Без этого они не обучатся использованию CUDRID, им будет трудно адаптироваться к CUDRID. Поэтому нужна такая техническая поддержка.

Кроме того, для всех этих процессов необходимо время. Нужно не спешить и понимать, что придется подождать. Мы уже 6 лет разрабатываем CUDRID. Мы растем, мы внедряем какие-то новые модификации, размещение на Oracle, MySQL и так далее.

Сейчас мы работаем над тем, чтобы развертывание систем можно было делать более широким или более узким. К настоящему времени в рамках "NHN" мы уже сделали более пятисот размещений CUDRID.

В ходе разработки CUDRID и внедрения его на наши сервисы, мы поняли, что не каждому сервису необходим Oracle или какое-то коммерческое решение. Мы доказали, прежде всего, самим себе и всем разработчикам нашей компании, что это не так.

Если Oracle справляется со многими задачами, это стабильные решения – хорошо. Но иногда нужны собственные решения, решения с открытым кодом. Тогда нет необходимости покупать очень дорогой мощный инструмент (от Oracle, например).

Какое место занимает CUDRID сейчас в Корее. Огромное число правительственных организаций (2/3 правительственных организаций) являются пользователями CUDRID. Менее популярна эта система на глобальном уровне. Но мы надеемся, что в ближайшие годы это изменится. Нам нужно время. Мы будем предлагать техническую поддержку, разрабатывать новые свойства, которые обеспечат совместимость с уже существующими решениями.

Я рад предложить вам это решение, которое мы разработали 6 лет назад буквально с нуля. Сейчас это очень мощная, стабильная система, которая предлагает огромное число параметров на уровне предприятия. Она может быть альтернативой коммерческим решениям. Мы гордимся этим!

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

Спасибо вам за внимание!

Ведущий: У нас еще есть примерно пять минут для вопросов. Пожалуйста, задавайте. Есен также говорит по-русски, вы можете задавать вопрос на русском языке. Он пояснит все, что нужно, Юджину – переадресует вопрос, если не сможет ответить сам.

 

Вопросы и ответы

Реплика из зала: Добрый день! Сейчас очень популярно движение NoSQL. Одна из ключевых вещей в нем – отказ от SQL-языка, который замедляет запросы и является таким узким местом. Планируете ли вы что-то подобное у себя применять.

Есен Сагинов (перевод): Давайте, я по-английски буду говорить. Постараюсь ответить на этот вопрос от себя. В нашей компании мы пользуемся решением NoSQL – это не проблема. Но есть множество web-сервисов, которые полагаются на SQL-серверы(/ сиквел-серверы?). Им не нужно NoSQL.

Я не говорю о том, что нам не нужен Oracle или что-то еще. Нам не нужен SQL. Мы можем использовать сервисы наши собственные. Например, очень популярный в Корее "Twitter me today"(?). Он опирается на MySQL.

Мы можем пользоваться NoSQL, а можем не пользоваться. Не каждое решение или приложение требует NoSQL. У нас есть средства перехода к NoSQL. Например, есть онлайновое средство коммуникации "Line", которое опирается на NoSQL. Все зависит от цели приложения. Не все требует именно NoSQL. Наша политика – следовать тому, что нужно.

Реплика из зала: Вопрос о девелопменте. Вы используете какие-то библиотеки типа STL или Boost, или вы все с нуля пишете самостоятельно?

Есен Сагинов (перевод): Пользуемся ли мы библиотеками типа Boost?

Реплика из зала (перевод): Библиотека Boost – это С++.

Юджин Стояновичи (перевод): Нет. CUBRID полностью написан в С. Этим мы не пользуемся. Алгоритмы в основном разрабатываются нами.

Конечно, в каких-то случаях библиотеки могут быть полезны. Библиотеки регулярных экспрессий, например. Они включаются в стандартные С-библиотеки. Но большую часть алгоритмов мы сами разрабатываем.

Есен Сагинов (перевод): Все в CUBRID нативно – происходит от нас. Мы не привлекаем какие-то внешние решения. Практически все мы делаем с нуля и сами.

Реплика из зала (перевод): У меня технический вопрос. Вы сказали, что планируете добавить масштабируемость, (кэленгаут?, 65:27) и поддерживать SQL и ACID. Как вы будете выполнять сложные SQL-запросы на множественных серверах?

Есен Сагинов (перевод): Хороший вопрос! Спасибо. Прежде всего, мы добавили новый параметр шардинга (или сегментирования). Но, в целом, это свойство будет масштабируемо, этот фичер будет масштабированной. Ничто не будет разбиваться, когда мы будем добавлять шардинг (то есть, сегментирование). Когда мы добавляем новый фичер, это не нарушает исходную архитектуру, не разбивает ее. Все опирается на транзакции.

Реплика из зала (перевод): Как вы собираетесь отслеживать эти транзакции на множественных серверах?

Есен Сагинов (перевод): Мы это уже сделали. Это технический вопрос, и здесь надо долго объяснять, как мы разрабатывали решение. Сначала надо будет саму архитектуру CUBRID описать. Давайте, мы это разберем уже в другом зале, где будет время для обсуждения. В зале для мастер-классов все это обсудим.

Во время перерыва на обед или после него мы будем в зале для мастер-классов. Он находится в конце коридора. Вы меня уже, наверное, в лицо узнаете. Можем там подробно и долго поговорить и о вопросах архитектуры.

(Аплодисменты).

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Александр Титов

Александр Титов

Руководитель отдела системного администрирования в компании Skype.

Доклад специалистов "Skype" об использовании решений Chef и Knife.

Александр Лямин

Александр Лямин

Руководитель Лаборатории Высоких нагрузок (Highload Lab).

Рассказ о такой услуге, как защита от DDоS, под кодовым названием «анализ интернет-трафика».

Роберт Вирдинг (Robert Virding)

Роберт Вирдинг (Robert Virding)

Главный специалист по языкам программирования в Erlang Solutions Ltd.

Роберт Вирдинг (Erlang Solutions Ltd.) рассказывает о том, как выглядит реализация Erlang изнутри и почему она масштабируется.