Какой sql выбрать

Как выбрать базу данных в sql

Для выбора базы данных в SQL необходимо использовать команду USE :

USE database_name; 

где database_name — это имя базы данных, которую вы хотите выбрать.

Например, чтобы выбрать базу данных с именем mydatabase, необходимо написать следующую команду:

USE mydatabase; 

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

Какую СУБД выбрать и почему? (Статья 1)

Это первый выпуск в серии статей про СУБД , в рамках которых буду достаточно простыми словами давать информацию про то, что сейчас есть на рынке баз данных, и что выбрать для решения своих задач.

Заметил, что когда спрашиваешь кого-нибудь, особенно на собеседовании, какие типы СУБД существуют, то первое что вспоминают многие – это реляционные базы данных, и NoSQL, а вот про разновидности часто забывают или не могут сформулировать их отличие. Поэтому начнем с простого перечисления наиболее используемых.

1. Реляционные
2. Ключ-значение
3. Документные
4. Графовые
5. Колоночные

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

Нужно обязательно сделать ремарку, что некоторые крупные производители, имеют в своем арсенале несколько типов СУБД, как в виде отдельных продуктов, так и в виде внутренней реализации. Например, у Oracle на самом деле чего только нет, начиная с классической реляционной СУБД, продолжая с отдельным продуктом Oracle NoSQL Database, который может использоваться и как документная, и как колоночная, и как ключ-значение. Отдельное решение от того же Oracle, Autonomous Data Warehouse – это уже специализированное решение для хранилищ данных. Еще один отдельный продукт от Oracle – Oracle Graph Server для работы с графами, и еще много другого. Этому можно посвятить отдельную серию статей.

Реляционные СУБД

Начнем по порядку, классические, реляционные СУБД чаще всего используются для построения решений OLTP (Online Transaction Processing). В таких решениях СУБД работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом от системы требуется минимальное время отклика, а так же возможность, при определенных условиях, отменить любые изменения выполняемых в рамках транзакции. Если вы строите систему, в рамках которой требуется хранить значительное количество сущностей (таблиц), с различными типами связей между ними (один-к-одному, один-к-многим, многие-ко-многим), то это скорее всего про реляционные СУБД.

Наиболее известные СУБД такого типа — Oracle, Microsoft SQL, PostgreSQL, MySQL.

Когда выбирать реляционную СУБД

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

Когда не выбирать реляционную СУБД

Если предполагается хранить не структурируемые данные, или наоборот очень простые структуры типа ключ-значение, то лучше посмотреть в сторону документных СУБД и специализированных СУБД типа ключ-значение соответственно.

Так же один из признаков, что имеет смысл подумать не о реляционных СУБД, это такой факт как необходимость часто обновлять значения в одних и тех же строках. Обычно это обходится «дорого» в реляционных СУБД, и нужно применять «продвинутую магию» что бы делать это корректно.

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

СУБД типа ключ-значение

Наверное один из самых простых типов СУБД. В упрощенном виде, это некая таблица с уникальным ключом и собственно связанным с ним значением, в котором может быть что угодно. Чаще всего такие СУБД используют для кэширования, т.к. они очень быстро работают, а это и не сложно, когда есть уникальный ключ, и запрос возвращает только одно значение. У некоторых представителей данных СУБД есть возможность работать полностью в памяти, а так же есть возможность задавать срок жизни записи, после истечения которого, записи будут автоматически удаляться.

Наиболее известные СУБД такого типа — Redis и Memcached.

Когда выбирать СУБД ключ-значение

Если СУБД будет использоваться для кэширования данных или для брокеров сообщений, то это очень подходящий тип. Так же, такая СУБД хорошо подходит для баз где нужно хранить достаточно простые структуры, и иметь к ним очень быстрый доступ.

Когда не выбирать СУБД ключ-значение

Если вы предполагаете хранить в базе данных много сущностей (таблиц), а у сущностей будут сложные структуры с разными типами данных. Так же, если вы предполагаете делать из этой таблицы сложные запросы которые возвращают множества строк.

Документные СУБД

Документные или документно-ориентированные СУБД — это одна из наиболее популярных разновидностей NoSQL СУБД, где основной единицей логической модели данных является документ — структурированный текст, с определенным синтаксисом.

Иногда встречаются мнения что модель данных в документных БД похожа на модель данных в объектно-ориентированных базах данных. В этом есть доля правды, единственная реальная разница между ними заключается в том, что базы данных документов только сохраняют состояние, но не поведение.

Так же, само название «документо-ориентированная» подчас вводит в заблуждение, и мне встречались коллеги, которые считали, что это база для систем документооборота. Нет, это не так.

Интересно, что документные СУБД развиваются достаточно активно, и сейчас некоторые из них, в том числе, поддерживают проверку схемы.

Известными представителями таких СУБД являются CouchDB, MongoDB, Amazon DocumentDB.

Когда выбирать документную СУБД

Если нужно хранить объекты в одной сущности, но с разной структурой. Если нужно хранит структуры, включая объекты, списки и словари, особенно в формате близкому к JSON.

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

Когда не выбирать документную СУБД

Не самое лучшее решение для реализации транзакционная модели, и точно не лучший вариант для формирования отчетности.

Графовые СУБД

Графовые СУБД — специфичный тип, предназначены для работы с графами, с их узлами, свойствами, и произвольными отношениями между узлами.

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

Известные представители этого типа субд — Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid.

Когда выбирать графовые СУБД

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

Когда не выбирать графовые СУБД

Практически во всех остальных случаях, кроме указанных выше, лучше воздержаться от использования графовых СУБД.

Колоночные СУБД

Колоночные СУБД очень похожи на реляционные. Они так же состоят из строк, которые имеют атрибуты, а строки группируются в таблицах. Различия в логических моделях несущественные, а вот на уровне физического хранения данных различия значительные.

В реляционных СУБД данные хранятся «построчно», это означает что для считывания значения определенной колонки, придется прочитать практически всю строку, как минимум от первой до нужной колонки. В колоночной СУБД данные хранятся «поколоночно», т.е. колонка — это как отдельная таблица. Соответственно чтение будет происходить из конкретного столбца сразу. На практике это реально работает очень быстро (проверено мной на нескольких реализованных хранилищах данных).

Основные преимущества колоночных СУБД – эффективное выполнения сложных аналитических запросов на больших объемах, и легкое, практически мгновенное, изменение структуры таблиц с данными, плюс существенная компрессия и сжатие, которое позволяет значительно экономить место.

Яркие представители колоночных СУБД — Sybase IQ (ныне SAP IQ), Vertica, ClickHouse, Google BigTable, InfoBright, Cassandra.

Когда выбирать колоночные СУБД

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

Когда не выбирать колоночные СУБД

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

Нужно так же иметь ввиду, что в колоночных СУБД могут быть и другие ограничения. Например, может отсутствовать поддержка транзакций, а язык запросов может отличаться от классического SQL, и прочее.

Итоги

Важное замечание – не пытайтесь сразу все задачи решить в рамках одной СУБД. Это более чем нормально иметь несколько разных типов СУБД. Так же, не пытайтесь сразу определиться с производителем СУБД, или связать свою жизнь с одним конкретным брендом.

При выборе типа СУБД следует, прежде всего, исходить из типа решаемых задач, типов обрабатываемых данных, перспектив роста и масштабирования.

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

В данной статье я намеренно не делаю акцент на выбор между облачными и on-premise решениями — эта тема одной из следующих статей.

Итак, в таблице представленной ниже, кратко собрано то, что описано выше в статье.

Тип СУБД

Когда выбирать

Примеры популярных СУБД

Нужна транзакционность; высокая нормализация; большая доля операций на вставку

Oracle, MySQL, Microsoft SQL Server, PostgreSQL

Задачи кэширования и брокеры сообщений

Для хранения объектов в одной сущности, но с разной структурой; хранение структур на основе JSON

CouchDB, MongoDB, Amazon DocumentDB

Задачи подобные социальным сетям; системы оценок и рекомендаций

Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid

Хранилища данных; выборки со сложными аналитическими вычислениями; количество строк в таблице превышает сотни миллионов

Vertica, ClickHouse, Google BigTable, Sybase \ SAP IQ, InfoBright, Cassandra

Надеюсь данная статья оказалась полезной.

В следующих статьях посмотрим на выбор между облачными и on-premise СУБД, платными и бесплатными, и многое другое.

Рассуждение на тему, какую базу данных выбирать

Я разберу в своей статьи некоторые типичные и не очень варианты выбора баз данных, а если быть более точным — подходы к выбору. Когда следует остановится на том, что используют большинство, а когда можно и задуматься над новым и неизведанным. Я опишу СУБД MySQL, PostgreSQL, MongoDB, Redis, CouchDB/PouchDB и упомяну о Aerospike с Tarantool, парочку других — но в некоторых моментах конкретный выбор не настолько принципиален. Надо понимать, что лучше изначально правильно спроектировать структуру данных, чем выбрать СУБД, а потом уже пытаться придумывать, что в ней собственно хранить.
Итак, начнем.

Небольшие отступления:

1. Мои выкладки не истина в последней инстанции. Какие-то выводы я делал на основе реального использования, какие-то на основе информации в интернете, обсуждения с другими людьми. Некоторые выводы сделаны на основе реальных задач, а некоторые в чисто теоретических идеях. Вся эта информация есть в том или ином виде на просторах интернета, но достаточно разрознена, я же постараюсь компактно описать в одном месте.
2. Я рассматриваю только те продукты, которые на момент написания статьи активно развиваются и в то же время стабильно существуют в течении длительного времени. Опять же, на мой взгляд, одним из условий выбора чего-либо для своего проекта — чтобы продукт был достаточно стабильный, рабочий, имел большое и хорошо развитое сообщество, его использование не сопряжено с многодневными танцами с бубном и т.п. И что немаловажно — должна быть возможность официально воспользоваться коммерческой поддержкой и получить тем самым гарантии от разработчика. Следует учитывать, что есть множество других вариантов, но они либо сырые и для их сопровождения в проекте придется прикладывать дополнительные и нерациональные усилия. Либо гораздо менее успешны или популярны.
3. Я с удовольствием почитаю ваше мнение в комментариях. И об описанных базах данных и не только. И не только я, думаю многим будет интересно почитать аргументированное мнение о какой либо базе данных.
4. Самое важное и еще раз — здесь не пойдет речь про крупные проекты. В таких проектах обычно уже есть свой архитектор или знающий человек и достаточно средств, чтобы обеспечить оптимальный выбор. Хотя кто знает, может мои выкладки и им пригодятся.

Теперь давайте зададим себе вопросы:

• Насколько вы консервативны, хотите и любите ли вникать во что-то новое?
• Хотите не думать или наоборот хотите вникнуть досконально в устройство базы данных?
• Насколько хорошие программисты в вашей команде, смогут ли они грамотно составить структуру БД или они уже являются отличными специалистами по какой-то одной СУБД?

MySQL / MariaDB

Народная СУБД или «must have», есть практически на любом хостинге. Простая в установке, работает нормально без особых настроек. При должном подходе может гибко настраиваться под ваши нужды. Но есть и подводные камни, в некоторые случаях она будет тем самым узким горлышком и ваш проект будет тормозить, как бы вы не тюнинговали СУБД и структуру данных.
MySQL для вас, если:

— вы консерватор и не хотите вникать в настройки СУБД, просто поставили и работает (ну или на хостинге используете то, что дают);
— вы консерватор же, значит мыслите структурно, таблично. MySQL справится;
— в любом языке программирования, фреймворке, CMS, CMF и так далее и тому подобное — есть интеграция с MySQL.
— вы новичОк и вам нужна СУБД для управления структурными данными, желательно небольшими (до 1 — 2 гигабайт).

Минусы? Их есть и вам следует выбрать другую СУБД, если увидите важное.

— посредственная производительность. Действительно низкая, как не тюнингуй. даже кластер не поможет особо (его еще настроить надо, ага, те еще танцы с бубном). Речь о цифрах порядка 20 МБайт/сек. Из личного опыта, на SSD дисках при таком потоке MySQL упирался в свой предел, не справлялся и тормозил, причем сервис настраивался несколько лет, использовались оптимальные для нагрузки настройки. Из коробки конфигурацию, думаю будет еще меньше планку иметь;
— изменение структуры данных может быть довольно трудоемким процессом, особенно при большом количество связей между данными в разных таблицах и даже при простом добавлении полей;
— чувствительность к нестабильности сервера. Особенно это влияет при использовании XtraDB от Percona. Если неправильно завершить MySQL, можно настолько поломать таблицы и базы данных, что восстановить можно будет только из полного бекапа, конечно, если вы их регулярно делаете. И поверьте, это случается всегда в самый неожиданный момент. Есть инструменты, которые в несложных ситуациях помогут восстановить работоспособность, но они не панацея. В последних и актуальных версиях активно борются с этим, заявлена гораздо лучшая стабильность и надежность.

PostgreSQL

Своего рода мастодонт, очень старая и грамотная СУБД. Она почти как MySQL, только лучше. Но надо уметь готовить и настраивать. По мнение многих, очень стабильная СУБД, ее практически невозможно уронить, порушить таблицы как в MySQL. И это может быть для вас решающим фактором при выборе.

PostgreSQL для вас, если:

— вы консерватор (понимаю повторяюсь, но так и есть) и нужно надежное хранилище;
— вы или ваш специалист умеете настроить и использовать PostgreSQL;
— вам нужны хорошо структурированные данные, но с некоторой гибкости в схеме данных (JSON/BJSON);
— при помощи сторонних библиотек просто и удобно расширяться в кластеры и делать шардинг таблиц. И все это действительно работает.

А минусов как то вот не особо описывать… Справедливости ради, особо практики не имел, в основном сужу по рассказам знакомых:

— необходимость опыта работы с этой СУБД, чтобы приготовить ее хорошо. Иначе лучше взять MySQL или прочитать дальше;
— система авторизации по умолчанию может вызвать затруднения при использовании или настройке, далеко не всем нравится, некоторые даже очень опытные разработчики до сих пор не до конца понимают как оно там работает.

MongoDB

О, сколько копий до сих пор ломается — SQL или NoSQL… Но все же в некоторых случаях MongoDB справляются с задачей гораздо лучше, чем MySQL или PostgreSQL. Например, реальный случай, свидетелем которого я был — сбор и обработка статистики по хостингу (нагрузка на CPU, i/o, память и т.п.) — MySQL не справился от слова вообще. MongoDB справился без особых проблем. База данных достигает объема в 200-300 ГБайт, поток данных достигает 100 и более МБайт/сек. Показательно, на мой взгляд.

MongoDB для вас, если:

— у вас нет четкой, заранее описанной структуры данных или вы предполагаете, что состав данных может потом сильно изменится (конечно это можно делать в SQL, но надо мыслить другими понятиями, поменять то можно, но вопрос насколько это будет трудоемко);
— у вас планируется довольно серьезный объем данных (десятки или даже сотни ГБ), определить это даже на этапе ТЗ можно;
— вам просто хочется NoSQL, модно же;
— легко установить и попробовать, работает нормально без особых настроек. А если углубится, изучить, то настроить можно очень многое.

Минусы тоже есть.

— Нет простых транзакций. По крайней мере в том, классическом виде, какие они есть в MySQL/PostgreSQL. При добавлении множества данных, которые зависят друг от друга, могут быть определенные трудности, которые придется решать самостоятельно на уровне кода. Ну то есть вы можете и не столкнутся конечно, но…;
— связность данных практически отсутствует. Сразу приходит на ум, постоянно упоминают JOIN из SQL — вот этого по сути нет. Хотя, если быть более точным, то надо просто мыслить другими категориями;
— нужно перестраивать мышление именно под NoSQL. иначе будет сложно сопровождать — то есть хороший программист (точнее архитектор ПО) обязателен в дальнейшем.

Redis

Чаще всего эту СУБД используют в качестве кеширующего слоя для работы с данными из другой, более медленной СУБД. Лучшая замена memcached, если вам это что-то скажет. Редко, но все же может использоваться в качестве самостоятельно БД для данных. При этом Redis умеет разные типы данных, в том числе списки, очереди, умеет Pub/Sub, а еще очень просто работать с TTL (время жизни ключа). Работает в памяти, очень быстрая, умеет сохранять данные на диске, причем с поддержкой дозаписи (гораздо меньше нагружает диск) и загружать при запуске. Почти сказка.

Redis для вас, если:

— объем данных небольшой и очень простая схема, укладывающая в шаблон «ключ=значение»;
— простая реализация репликации Master — Slave. Действительно очень простая настройка, достаточно добавить в конфиг сервера указания на мастера, запустить Redis Server и данные уже реплицируются. Хотя, наверное, следует уточнить, что настроить гибкую репликацию (частичную) вряд ли получится;
— нужен Pub/Sub (очереди). Справедливости ради следует сказать, что есть отдельные системы Pub/Sub, реализующие помимо этого паттерна и другие. Redis реализует это достаточно элегантно и просто, вполне возможно вам другие не понадобятся;
— нужен кеш для более медленной СУБД или просто хотите не задумываться о скорости работы СУБД с оглядкой на ее объем. Примером может послужить сайт на Drupal, с основной базой данных в MySQL и кешем в Redis. Проводил тесты ради интереса обычным ab, скорость отдачи контента может увеличится в разы. На обычном Apache + Redis + mod_php можно достичь сравнимой производительности с Nginx + php-fpm, а если к Nginx добавить Redis…

Минусы тоже есть, как же без них.

— объем данных не должен превышать объем свободного ОЗУ на вашем сервере (на самом деле может, но тогда все они будут уходить в swap, сильно замедлять работу, в общем лучше избегать);
— в угоду производительности присутствует довольно слабая сохранность данных. То есть вполне может произойти такое, что данные добавили, а после рестарта их нет. Включение AOL (append of file) немного сглаживает ситуацию, но тогда загрузка с диска будет довольно длительной;
— транзакции и связанные данные не то, чтобы умеет. Если точнее — есть Pipeline и Multi/Exec, но это все таки не совсем транзакция в классическом понимании;
— до сих пор не умеет нормально кластер и шардинг. Нормальной реализации до сих пор нет.

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

Альтернативы

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

IBM Lotus Domino/Notes

На мой взгляд ярчайший пример успешного коммерческого проекта СУБД концепции NoSQL. Хотя подозреваю, что успех скорее не в его NoSQL, а в наличии полноценного сервера приложений с встроенным редактором кода и интерфейса к базе. Решение очень зрелое, существует на рынко довольно давно и поддерживается гигантом IBM — ну то есть очень даже круто. Лично участвовал в разработке двух разных систем электронного документооборота на его базе, а также сопровождал некоторые критично важные приложения в банке. Кстати, несмотря на платную политику распространения, мало кто знает, но его можно бесплатно скачать для изучения.

CouchDB

Хотите хранить документы разной структуры (ну как MongoDB, типа), но у вас нет для приложения адаптера или не хотите лишних зависимостей? CouchDB работает через http, имеет встроенный веб-сервер, обменивается в JSON. Очень удобно. Кстати умеет транзакции и можно подписываться на изменения данных. Но это не точно.

PouchDB

Это очень интересный проект, как бы аналог CouchDB, но более приземленный, встраиваемый вариант. Встроили в приложение, работает как локальная база данных, но умеет настраиваемую репликацию с CouchDB или PouchDB Server (на базе ExpressJS). PouchDB на самом деле скорее прослойка, где снаружи вы работаете с единым API, CouchDB-подобным, но внутри может быть совсем разные СУБД — и SQLite и LevelDB и браузерная база данных и MongoDB и даже MySQL. Очень пригодится, если вы делаете распределенное приложение, где обмен данными важен, но связь с сервером может быть нестабильной или эпизодической.

Aerospike

На мой взгляд отличная замена Redis в плане key/value БД. Умеет транзакции, умеет сохранность данных, умеет большой объем данных (превышающий объем доступной ОЗУ). Правда нет Pub/Sub и каких-то особых структур данных, но работает быстро и хорошо. Пожалуй единственным недостатком это слабая популярность по сравнению с Redis. Непонятно кстати почему…

Apache Cassandra

Спроектирована и работает как распределенная NoSQL СУБД для больших данных. Данные хранит в виде семейства столбцов, что сперва может изменить кардинально подход к разработке приложения. Но после ломки мышления вполне может оказаться, что это именно то, что вам надо. Заявлено простое добавление узлов на лету, высокая отказоустойчивость при выходе одного из узлов. В теории можно использовать на небольших проектах, но выглядеть будет наверное, как будто микроскопом забивать гвозди.

Tarantool

Замечательный проект от Mail.Ru. Что-то среднее между Redis/Aerospike и MongoDB… Хотя по моему сами разработчики до сих пор затрудняются провести аналогии :). Его надо уметь, а если быть более точным хотеть готовить. И речь не про настройку, а про постоянную подгонку под разработку новых версий Tarantool. Нужно хотеть вникать во внутреннее устройство этого проекта, постоянно изучать изменения его API и документации, все время подгонять код приложения под изменения. А если вы еще и хотите поучаствовать в процессе разработки, пообщаться с разработчиками в чате — тогда тем более это для вас.

А вот теперь как бы и все.

Да, я упомянул далеко не все СУБД (если смотреть на этом сайте, то там перечислено 253 названия). Надеюсь вы и не думали, что я их все перечислю?

Возможно в описании той или иной СУБД я допустил неточность и не упомянул нечто важное. Такое очень даже возможно и если так — напишите в комментариях, я с интересом почитаю.
Надеюсь мои выводы окажутся полезными и интересными.

UPD1: По поводу отказоустойчивости MySQL. Вы все правы. Я не заявляю, что InnoDB нестабильна, я лишь упомянул, что ситуация это возможна. И если она произойдет, то восстановить работоспособность никак нельзя будет, только начисто восстанавливать все целиком из бекапа. Именно об этом речь, а не о том, что вы решили будто я считаю ее нестабильной. По реальному примеру, на серверах у нас такое произошло за последний год 2 или 3 раза. На разных серверах. На сервере несколько сотен баз с разной нагрузкой, объемов и т.п. Это не значит, что у вас MySQL будет падать регулярно на виртуалке с одним-двумя сайтами, совсем не об этом речь. Как то так.

• MySQL
• NoSQL
• MongoDB
• Администрирование баз данных

Как выбрать быстрый и надежный сервер для баз данных SQL, 1C и терминалов

От правильной конфигурации сервера зависит работа IT-инфраструктуры предприятия. Чем крупнее компания и чем больше обращений к данным в течение дня, тем критичнее ошибки, допущенные на этом этапе.

Какие требования предъявляют к современным серверам

• Скорость. Чем быстрее сервер, тем эффективнее работает предприятие. Время, сэкономленное на выполнении операций ввода-вывода, является одним из базовых конкурентных преимуществ компании.
• Отказоустойчивость. Серверы работают без отключения в течение нескольких месяцев, а то и лет подряд. Они испытывают постоянную высокую нагрузку, которая может привести к неисправностям. Отказоустойчивость представляет собой свойство сервера сохранять работоспособность после отказа одного или нескольких составных компонентов.
• Сохранность информации. Консолидированная на серверах информация – пожалуй, важнейшая нематериальная ценность компании. Корректно подобранное оборудование и ПО к нему позволяют защитить ее от повреждения, утери и доступа третьих лиц.

Сервер Dell PowerEdge R740

Цена от $ 2 099. 00
Сконфигурировать

Сервер HPE Proliant DL380 Gen10

Цена от $ 2 311. 00
Сконфигурировать

Сервер Fujitsu Primergy 2540 M4

Цена от $ 2 099. 00
Сконфигурировать

Как выбрать сервер для работы с БД

В зависимости от задач, которые сервер будет решать на предприятии, критерии его выбора незначительно отличаются. Однако базовые параметры, на которые необходимо обратить особое внимание, одинаковы. Рассмотрим их на примере сервера баз данных SQL.

Тип дисковых накопителей

Рекомендуется использовать постоянную память с самым быстрым доступом. Чем выше требования к производительности сервера, тем больше операций ввода-вывода он выполняет в единицу времени (стандартная единица – IOPS, или количество таких операций за 1 секунду). В настоящее время используются устаревшие механические диски типа SATA и SAS, в которых скорость работы напрямую определяется частотой вращения шпинделя. Если в первом случае мы имеем 7 200 об/мин., то во втором – уже 10 000 – 15 000 об/мин. Однако самыми быстрыми являются SSD-диски – твердотельные накопители. Если взять высокопроизводительный SAS-диск и сравнить его с SSD, то при одинаковом объеме и стоимости в первом случае мы получим около 150 IOPS, а во втором – в десятки раз больше. Соответственно, использовать SSD-диски рациональнее для получения максимальной производительности.

Работу современного сервера баз данных невозможно представить без RAID-массива – технологии виртуализации данных, которая подразумевает объединение нескольких физических дисков в один виртуальный. Оптимальный выбор для СУБД – зеркальный дисковый массив RAID 10. Его преимущества:

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

Недостаток у такого решения заключается в том, что суммарный объем виртуального диска в RAID-массиве будет равен объему одного физического накопителя. Например, если использовались два SSD-диска по 500 Гб, объем массива RAID 10 также составит 500 Гб.

Еще один популярный вариант объединения дисков – технология RAID 0. В этом случае объемы физических дисков суммируются, но при повреждении любого из них часть данных потеряется, так как дублирование не выполнялось. Главный плюс такого решения – увеличение итогового объема виртуального пространства. При объединении двух SSD-дисков по 500 Гб размер массива RAID 0составит 1000 Гб.

Мы рекомендуем остановить выбор на массиве RAID 10 как оптимальном по скорости работы и надежности хранения данных.

Оперативная память

Здесь действует простой принцип: чем больше, тем лучше. Больше ОЗУ – значит, быстрее будет обрабатываться информация. При обращении к БД, сохраненной на сервере, данные будут кэшироваться в оперативной памяти. Наибольшая производительность достигается в том случае, когда объемы ОЗУ и дискового пространства одинаковы.

Процессор

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

Как выбрать терминальный сервер

В случае с терминальным сервером по-прежнему отдается предпочтение надежным и быстрым дискам, объединенным в RAID-массивы. Другие значимые параметры:

• объем оперативной памяти. Рассчитывается в зависимости от типа запускаемых на терминале приложений (офисные, графические и другие) и продолжительности терминальной сессии. Среднестатистическая терминальная сессия требует около 512 Мб оперативной памяти;
• количество ядер процессора. В среднем каждое ядро процессора может обслужить 6–8 пользователей, одновременно обращающихся к серверу.

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

Как выбрать сервер для работы 1С

В общем случае сервер 1С включает в себя три сервера:

• СУБД, построенная на основе формата DBF или Microsoft SQL;
• сервер приложений, который обращается к СУБД;
• терминальный сервер, к которому подключаются пользователи 1C.

На небольших предприятиях все три функции выполняет один физический сервер или аппаратный кластер, состоящий из двух серверов и СДХ. Для организации логических серверов используется технология виртуализации. Если пользователи 1C активно используют офисные приложения, CRM-систему или другое ПО, кластер расширяют до трех серверов.

При выборе физического сервера для 1С можно смело руководствоваться критериями, изложенными в предыдущем разделе. Важными остаются типы используемых накопителей, технология виртуализации и объем оперативной памяти. Но добавляется еще один параметр: частота процессора, которая напрямую определяет скорость обмена информацией между процессором и другими компонентами сервера.

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

Вам может быть интересно: