Жизнь после MySQL: выбираем замену для популярной СУБД. Статья для журнала Хакер
Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант, без правок или ограничения на объем материала.
Oracle, купив Sun, подготовило закат солнца вручную, медленно убивая самую лучшую СУБД в мире – MySQL. Но что делать, если очень хочется быстрой и свободной базы, но без призрака оракла за спиной?
Твой любимый форум работает на MySQL (на мускуле, если кратко), а на работе или в вузе крутиться система учета чего-либо, написанная твоими друзьями под пиво и за получение зачета? И тоже на мускуле? Да в вебе тысячи и миллионы сайтов используют MySQL как базу данных. Но что будет теперь, когда ненавистный и глубоко противный истинным опен-сорсникам Oracle купил многострадальную Sun, а заодно и наш с тобою любимый мускул? От неудачников, кинувших даже ЦРУ, не стоит ждать качественного развития свободных проектов. Да-да, я отвечаю за базар – первым проектом молодой компании Oracle была разработка по заказу разведчиков какой-то учётной системы, за которую на конкурсе другие компании просили под 2 млн, а молодой Ларри Элисон заносчиво запросил за все жалкие 300 тысяч. Стоит ли говорить, что проект был провален, зато компания получила стартовый капитал и начала свое восхождение. Хотя уже поздно бить тревогу, все пацаны давно в курсе, что лучший (читай – наименее ущербный) движок для хранения данных в мускуле – это InnoDB, права на который у Oracle были давным давно. Так что, если ты сейчас чешешь репу, что бы выбрать взамен MySQL, ты удачно открыл журнал, я расскажу, чем можно заменить поделие империи зла. Но не беги с криками «да ваш мускул г…, бери слона (PostgreSQL) и будет все зашибись» - сейчас столько кода написано с поддержкой мускула, и зачастую в виде единственной базы данных, что переписать или искать замену себе дороже, а часто просто невозможно. Хорошо, если это форум или блог, обычно там сразу поддержка нескольких систем, а если что-то самописное и заточенное под возможности именно MySQL? Так что задача у нас с тобой самая что ни на есть простая – сохранить мускулы, но прокачав их так, чтобы не зависеть от старшего тренера и его стероидов. Oracle, конечно же, выступила с заявлением, что все в порядке и будут развивать все по старому, но никто как всегда не поверил. Даже быстрый выпуск версии 5.5, которую многие ожидали, не дал положительных результатов – старые баги как были, так и остались, но по маркетинговым заявлением все ОК.
Разработчики и идеологи самого мускула далеко не дураки и сами предвидели ситуацию, что после поглощения всем будет не очень сладко, поэтому некоторые решили покинуть от греха подальше компанию и основать свои проекты, прихватил тогда еще свободные коды MySQL. Таким образом, сейчас есть несколько проектов, которые взяли за основу оригинальный сервер, но постепенно дописывали или переписывали все, до чего могли дотянуться. И первым делом – освободились от бремени InnoDB, правами на который обладает тот самый Oracle. На замену ему выкатили несколько движков, основной из которых – MariaDB. Читать далее...
Приветствую наших читателей. Некоторый перерыв в публикациях был связан с моей командировкой в Киев и последующей срочной работой, впрочем, сейчас я уже могу выкроить время для новой публикации. На этот раз я вспомнил забытой мною рубрике интересных материалов и, посмотрев на открытые вкладки и закладки с тем, что меня заинтересовало, понял, что "забывать дальше" эту рубрику никак нельзя. Ведь сегодня в сети очень много материалов, вместе с этим качественные и интересные ещё нужно поискать. Этим то мы и займёмся. Приятного и, главное, полезного чтения. 
Приветствую наших читателей. Это будет эксклюзивный материал - я получил приглашение для тестирования новейшего сервиса Cloud Computing от компании Aptana. 
Приветствуем наших читателей. Не так давно 
Приветствуем наших читателей. Сегодня у нас нетривиальная статья-исследование. Честно говоря, я ещё сам не знаю, выйдет ли из него что-то стоящее и рабочее, но попытаться стоит. Спросите почему? Сейчас. Начнём с основных понятий. И так, JDBC - это, если расшифровать, Java Database Connectivity, то есть, специальный API для Java, который позволяет унифицировать доступ к различным базам данных, вне зависимости от типа СУБД. Концепция JDBC основана на понятии "драйвера", который может загружаться в во время выполнения и отвечает за унификацию доступа к СУБД. Этот API входит в стандартную поставку Java (в пакете java.sql). Расшифровывать PHP мы не будем, надеюсь всем понятно. Но открыт вопрос "зачем?". Если вы постоянный читатель нашего блога, вы могли заметить несколько статей о различных JDBC драйверах, позволяющих организовать пулы коннектов, кластеризацию и отказоустойчивость соединения с базой данных, таким образом организовать высокопроизводительный интерфейс для доступа к СУБД, причём, не привязываясь к определённым особенностям базы данных. Но вот для РНР такого, к сожалению нет, из встроенных интерфейсов доступа есть только mysqli и PDO, теперь ещё появился вариант mysqlnd (это то, что касается СУБД MySQL). Таким образом, для построения отказоустойчивой архитектуры на базе РНР и MySQL необходимо применять сторонние решение - систему кластеризации MySQL, MySQL Proxy или ещё что-то. Но ведь наши друзья-разработчики из мира Java могут иметь это все (в первую очередь, пул коннектов и кластеризацию) прямо "out of the box", применяя просто нужный JDBC драйвер (например, описанный нами HA-JDBC). Непорядок, сказал себе я вчера, и пошёл исследовать тему взаимодействия приложений на РНР и баз данных через JDBC.
Приветствую наших читателей. В сегодняшнем мире Ajax и сложных интернет-приложений построение высокопроизводительной архитектуры с одной стороны, способной обслуживать тысячи и миллионы запросов, и обеспечение взаимодействие с другими сервисами, как в рамках своей системы, так и интеграция со сторонними приложениями, используя базовые стандартные протоколы, как ни когда актуальна, согласитесь. Для решения первой задачи применяют различные методы и подходы, но основным считается сначала применение различного рода оптимизации (поясню, что здесь и далее речь идёт о СУБД 
Приветствую наших читателей. Если вы разрабатываете какую-то распределённую систему, или просто так сложилось, что существуют несколько баз данных (серверов), которые разнесены в пространстве, и между которыми нужно, с одной стороны, обеспечить синхронизацию данных, с другой - каналы связи не позволяют настроить полноценную репликацию, а над данными ещё бы хотелось и проводить какие-то несложные операции во время синхронизации, фильтровать их, да и избежать перегрузки как серверов, так и серверов, в случае если их несколько десятков или даже сотен. Вы считаете, что это редкая проблема и её только в NASA решают? Ну, к примеру, системы распределённых платёжных или торговых терминалов - их вполне в развитой сети может быть несколько тысяч, и нужно постоянно синхронизировать с одним или несколькими основными серверами, причём это вполне может быть и многоуровневая архитектура. А ещё хочется, чтобы такое решение было простое, бесплатное, то есть open-sourсe, и работало на любой платформе... Не спешите одёргивать себя от таких мыслей, все это вполне реально. Как? Используя 
Свежие комментарии