По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
SQL расшифровывается как Structured Query Language, или структурированный язык запросов. Команды SQL – это инструкции, которые даются базе данных для выполнения задач, функций и запросов с данными.
SQL-командами можно пользоваться для поиска по базе данных и выполнения различных функций: создания и удаления таблиц, добавления данных в таблицы и их редактирования.
Ниже приведен список основных команд (их иногда называют операторами), которые необходимо знать при работе с SQL.
SELECT и FROM
SELECT в запросе определяет, какие столбцы данных отобразить в результатах. Кроме того, в SQL есть возможности отображать данные не из столбца таблицы.
В примере ниже показаны 3 столбца, взятые из таблицы студентов Student (через SELECT и FROM) и один вычисляемый столбец. В базе данных хранятся ID (studentID), имя (FirstName) и фамилия (LastName) студента. Мы можем объединить столбцы с именем и фамилией и создать вычисляемое поле с полным именем (FullName).
SELECT studentID, FirstName, LastName, FirstName + ' ' + LastName AS FullName
FROM student;
Вывод:
+-----------+-------------------+------------+------------------------+
| studentID | FirstName | LastName | FullName |
+-----------+-------------------+------------+------------------------+
| 1 | Monique | Davis | Monique Davis |
| 2 | Teri | Gutierrez | Teri Gutierrez |
| 3 | Spencer | Pautier | Spencer Pautier |
| 4 | Louis | Ramsey | Louis Ramsey |
| 5 | Alvin | Greene | Alvin Greene |
| 6 | Sophie | Freeman | Sophie Freeman |
| 7 | Edgar Frank "Ted" | Codd | Edgar Frank "Ted" Codd |
| 8 | Donald D. | Chamberlin | Donald D. Chamberlin |
| 9 | Raymond F. | Boyce | Raymond F. Boyce |
+-----------+-------------------+------------+------------------------+
9 rows in set (0.00 sec)
CREATE TABLE
Название CREATE TABLE говорит само за себя – оператор создает таблицу. Вы можете задать название таблицы и настроить, какие столбцы будут присутствовать в таблице.
CREATE TABLE table_name (
column_1 datatype,
column_2 datatype,
column_3 datatype
);
ALTER TABLE
ALTER TABLE изменяет структуру таблицы. Вот так можно добавить столбец в базу данных:
ALTER TABLE table_name
ADD column_name datatype;
CHECK
CHECK ограничивает диапазон значений, которые можно добавить в столбец.
Когда вы настраиваете ограничение CHECK для отдельного столбца, оператор проверяет, что в этом столбце присутствуют строго определенные значения. Если же CHECK настраивается для таблицы, то он может ограничивать значения в отдельных столбцах на основании значений из других столбцов этой строки.
В следующем примере при создании таблицы Persons используется ограничение CHECK для столбца «Возраст» (Age). Таким образом проверяется, что в таблицу не попадают лица младше 18 лет.
CREATE TABLE Persons (
ID int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Age int,
CHECK (Age>=18)
);
Следующий синтаксис используется для присвоения названия оператору CHECK и настройки CHECK для нескольких столбцов:
CREATE TABLE Persons (
ID int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Age int,
City varchar(255),
CONSTRAINT CHK_Person CHECK (Age>=18 AND City='Sandnes')
);
WHERE (AND, OR, IN, BETWEEN и LIKE)
Оператор WHERE используется для ограничения количества возвращаемых строк.
Сначала, в качестве примере, мы покажем оператор SELECT и его результат без оператора WHERE. Затем добавим оператор WHERE, в котором используются сразу 5 из вышеуказанных квалификаторов.
SELECT studentID, FullName, sat_score, rcd_updated FROM student;
+-----------+------------------------+-----------+---------------------+
| studentID | FullName | sat_score | rcd_updated |
+-----------+------------------------+-----------+---------------------+
| 1 | Monique Davis | 400 | 2017-08-16 15:34:50 |
| 2 | Teri Gutierrez | 800 | 2017-08-16 15:34:50 |
| 3 | Spencer Pautier | 1000 | 2017-08-16 15:34:50 |
| 4 | Louis Ramsey | 1200 | 2017-08-16 15:34:50 |
| 5 | Alvin Greene | 1200 | 2017-08-16 15:34:50 |
| 6 | Sophie Freeman | 1200 | 2017-08-16 15:34:50 |
| 7 | Edgar Frank "Ted" Codd | 2400 | 2017-08-16 15:35:33 |
| 8 | Donald D. Chamberlin | 2400 | 2017-08-16 15:35:33 |
| 9 | Raymond F. Boyce | 2400 | 2017-08-16 15:35:33 |
+-----------+------------------------+-----------+---------------------+
9 rows in set (0.00 sec)
Теперь повторим запрос SELECT, но ограничим возвращаемые строки оператором WHERE.
STUDENT studentID, FullName, sat_score, recordUpdated
FROM student
WHERE (studentID BETWEEN 1 AND 5 OR studentID = 8)
AND
sat_score NOT IN (1000, 1400);
+-----------+----------------------+-----------+---------------------+
| studentID | FullName | sat_score | rcd_updated |
+-----------+----------------------+-----------+---------------------+
| 1 | Monique Davis | 400 | 2017-08-16 15:34:50 |
| 2 | Teri Gutierrez | 800 | 2017-08-16 15:34:50 |
| 4 | Louis Ramsey | 1200 | 2017-08-16 15:34:50 |
| 5 | Alvin Greene | 1200 | 2017-08-16 15:34:50 |
| 8 | Donald D. Chamberlin | 2400 | 2017-08-16 15:35:33 |
+-----------+----------------------+-----------+---------------------+
5 rows in set (0.00 sec)
UPDATE
Для обновления записи в таблице используется оператор UPDATE.
Условием WHERE можно уточнить, какие именно записи вы бы хотели обновить. Вы можете обновлять по одному или нескольким столбцам сразу. Синтаксис выглядит так:
UPDATE table_name
SET column1 = value1,
column2 = value2, ...
WHERE condition;
В примере ниже обновляется название записи (поле Name) с Id 4:
UPDATE Person
SET Name = “Elton John”
WHERE Id = 4;
Помимо этого, можно обновлять столбцы в таблице значениями из других таблиц. Чтобы получить данные из нескольких таблиц, воспользуйтесь оператором JOIN. Синтаксис выглядит так:
UPDATE table_name1
SET table_name1.column1 = table_name2.columnA
table_name1.column2 = table_name2.columnB
FROM table_name1
JOIN table_name2 ON table_name1.ForeignKey = table_name2.Key
В примере ниже мы обновляем поле «Менеджер» (Manager) для всех записей:
UPDATE Person
SET Person.Manager = Department.Manager
FROM Person
JOIN Department ON Person.DepartmentID = Department.ID
GROUP BY
GROUP BY позволяет объединять строки и агрегировать данные.
Вот так выглядит синтаксис GROUP BY:
SELECT column_name, COUNT(*)
FROM table_name
GROUP BY column_name;
HAVING
HAVING позволяет сортировать данные, которые собираются через GROUP BY. Таким образом, пользователю показывается лишь ограниченный набор записей.
Вот так выглядит синтаксис HAVING:
SELECT column_name, COUNT(*)
FROM table_name
GROUP BY column_name
HAVING COUNT(*) > value;
AVG()
AVG, или среднее, вычисляет среднее значение числового столбца из набора строк, которые возвращает оператор SQL.
Вот так выглядит синтаксис:
SELECT groupingField, AVG(num_field)
FROM table1
GROUP BY groupingField
А вот пример этого оператора для таблицы Student:
SELECT studentID, FullName, AVG(sat_score)
FROM student
GROUP BY studentID, FullName;
AS
AS позволяет переименовать столбец или таблицу с помощью псевдонима.
SELECT user_only_num1 AS AgeOfServer, (user_only_num1 - warranty_period) AS NonWarrantyPeriod FROM server_table
И вот так будет выглядеть результат.
+-------------+------------------------+
| AgeOfServer | NonWarrantyPeriod |
+-------------+------------------------+
| 36 | 24 |
| 24 | 12 |
| 61 | 49 |
| 12 | 0 |
| 6 | -6 |
| 0 | -12 |
| 36 | 24 |
| 36 | 24 |
| 24 | 12 |
+-------------+------------------------+
Кроме того, через оператор AS вы можете задать название таблицы – так будет проще обращаться к ней в JOIN.
SELECT ord.product, ord.ord_number, ord.price, cust.cust_name, cust.cust_number FROM customer_table AS cust
JOIN order_table AS ord ON cust.cust_number = ord.cust_number
Результат выглядит так.
+-------------+------------+-----------+-----------------+--------------+
| product | ord_number | price | cust_name | cust_number |
+-------------+------------+-----------+-----------------+--------------+
| RAM | 12345 | 124 | John Smith | 20 |
| CPU | 12346 | 212 | Mia X | 22 |
| USB | 12347 | 49 | Elise Beth | 21 |
| Cable | 12348 | 0 | Paul Fort | 19 |
| Mouse | 12349 | 66 | Nats Back | 15 |
| Laptop | 12350 | 612 | Mel S | 36 |
| Keyboard| 12351 | 24 | George Z | 95 |
| Keyboard| 12352 | 24 | Ally B | 55 |
| Air | 12353 | 12 | Maria Trust | 11 |
+-------------+------------+-----------+-----------------+--------------+
ORDER BY
ORDER BY позволяет сортировать результирующий набор данных по одному или нескольким элементам в разделе SELECT. Ниже дан пример сортировки студентов по имени (FullName) в порядке убывания. Изначально используется стандартная сортировка по возрастанию (ASC), поэтому для сортировки в обратном порядке мы применяем DESC.
SELECT studentID, FullName, sat_score
FROM student
ORDER BY FullName DESC;
COUNT
COUNT вычисляет количество строк и возвращает результирующее значение в столбце.
Ниже приводятся возможные сценарии использования COUNT:
Подсчет всех строк в таблице (не требуется Group by)
Подсчет общего числа подмножеств данных (в операторе обязательно прописывается Group By)
Этот оператор SQL выводит количество всех строк. Кроме того, что вы можете настроить название результирующего столбца COUNT с помощью AS.
SELECT count(*) AS studentCount FROM student;
DELETE
DELETE используется для удаления записи из таблицы.
Будьте внимательны! Вы можете удалить несколько записей в таблице, либо сразу все. С помощью условия WHERE вы указываете, какие записи необходимо удалить. Синтаксис выглядит так:
DELETE FROM table_name
WHERE condition;
Вот так выглядит удаление из таблицы Person записи с Id 3:
DELETE FROM Person
WHERE Id = 3;
INNER JOIN
JOIN, или внутреннее соединение, выбирает записи, соответствующие значениям в двух таблицах.
SELECT * FROM A x JOIN B y ON y.aId = x.Id
LEFT JOIN
LEFT JOIN возвращает все строки из левой таблицы и соответствующие им строки из правой таблицы. Строки из левой таблицы возвращаются даже при пустых значениях в правой таблице. Если для строк из левой таблицы нет соответствия в правой, то в значениях последней будет стоять null.
SELECT * FROM A x LEFT JOIN B y ON y.aId = x.Id
RIGHT JOIN
RIGHT JOIN возвращает все строки из правой таблицы и соответствующие им строки из левой. В отличие от левого соединения, здесь возвращаются все строки из правой таблицы, даже если им ничего не соответствует в левой. В таком случае, в значениях столбцов из левой таблицы будет стоять null.
SELECT * FROM A x RIGHT JOIN B y ON y.aId = x.Id
FULL OUTER JOIN
FULL OUTER JOIN возвращает все строки, соответствующие условиям в любой из таблиц. Если в левой таблице есть строки, которым ничего не соответствует в правой, то они все равно отобразятся в результирующих значениях. То же самое распространяется и на строки из правой таблицы без соответствующих значений в левой.
SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID=Orders.CustomerID
ORDER BY Customers.CustomerName
INSERT
INSERT используется для добавления данных в таблицу.
INSERT INTO table_name (column_1, column_2, column_3)
VALUES (value_1, 'value_2', value_3);
LIKE
LIKE используется в связке с WHERE или HAVING (в составе оператора GROUP BY) и ограничивает выбранные строки по элементам, если в столбце содержится определенный шаблон символов.
Этот SQL запрос выбирает студентов, чье значение в FullName начинается с «Monique» или заканчивается с «Greene».
SELECT studentID, FullName, sat_score, rcd_updated
FROM student
WHERE
FullName LIKE 'Monique%' OR
FullName LIKE '%Greene';
+-----------+---------------+-----------+---------------------+
| studentID | FullName | sat_score | rcd_updated |
+-----------+---------------+-----------+---------------------+
| 1 | Monique Davis | 400 | 2017-08-16 15:34:50 |
| 5 | Alvin Greene | 1200 | 2017-08-16 15:34:50 |
+-----------+---------------+-----------+---------------------+
2 rows in set (0.00 sec)
Перед LIKE вы можете добавить NOT, и тогда строки, соответствующие условию, будут исключаться, а не добавляться. Этот SQL исключает записи, у которых в столбце FULL NAME содержится «cer Pau» и «Ted».
SELECT studentID, FullName, sat_score, rcd_updated
FROM student
WHERE FullName NOT LIKE '%cer Pau%' AND FullName NOT LIKE '%"Ted"%';
+-----------+----------------------+-----------+---------------------+
| studentID | FullName | sat_score | rcd_updated |
+-----------+----------------------+-----------+---------------------+
| 1 | Monique Davis | 400 | 2017-08-16 15:34:50 |
| 2 | Teri Gutierrez | 800 | 2017-08-16 15:34:50 |
| 4 | Louis Ramsey | 1200 | 2017-08-16 15:34:50 |
| 5 | Alvin Greene | 1200 | 2017-08-16 15:34:50 |
| 6 | Sophie Freeman | 1200 | 2017-08-16 15:34:50 |
| 8 | Donald D. Chamberlin | 2400 | 2017-08-16 15:35:33 |
| 9 | Raymond F. Boyce | 2400 | 2017-08-16 15:35:33 |
+-----------+----------------------+-----------+---------------------+
7 rows in set (0.00 sec)
Rocket.Chat — это бесплатный масштабируемый open source корпоративный чат, разработанный с помощью Meteor. Rocket.Chat можно считать аналогом Slack, который можно развернуть на своем сервере, и подключаться к нему с клиентов на Linux, Windows, macOS, Android и iOS.
Функции Rocket.Chat
Чат в реальном времени
Аудиоконференции
Видеоконференции
Каналы
Гостевой вход
Трансляция экрана
Передача файлов
Полнофункциональный API
Для обеспечения безопасности используется:
Групповая синхронизация LDAP
Двухфакторная аутентификация 2FA
Сквозное шифрование
Единый вход SSO
Несколько поставщиков Oauth аутентификации
Рассказываем как установить и настроить сервер и клиент Rocket.Chat в Linux.
Шаг 1. Установка Snap в Linux
Для простоты мы будем использовать систему управления пакетами Snaps. Первым делом надо установить пакет snapd c помощью диспетчера пакетов.
$ sudo apt install snapd #Ubuntu и Debian
$ sudo dnf install snapd #Fedora 22+/CentOS/RHEL 8
$ sudo yum install snapd #CentOS/RHEL 7
Далее необходимо включить модуль systemd, который управляет основным сокетом мгновенной связи. Эта команда запустит сокет и позволит ему запускаться при загрузке системы.
$ sudo systemctl enable --now snapd.socket
Шаг 2: Установка Rocket.Chat в Linux
Для установки rocketchat-server выполните:
$ sudo snap install rocketchat-server
Когда установка через snap будет завершена, rocket.chat сервер начнет работать и прослушивать порт 3000. Далее откройте веб-браузер и введите следующий адрес, чтобы настроить rocket.chat через GUI.
http://SERVER_IP:3000
После загрузки мастера настройки укажите следующие параметры: полное имя администратора, имя пользователя, адрес электронной почты организации и пароль.
Далее надо указать информацию об организации: тип организации, название, отрасль, размер, страна и сайт.
Затем нужно указать информацию о сервере - имя сайта, язык, тип сервера, и включение или отключение двухфакторной аутентификации 2FA.
На следующей странице нужно зарегистрировать сервер. Здесь есть две опции. Первая - использовать предварительно настроенные шлюзы и прокси, предоставленные Rocket.Chat Вторая - сохранить автономность и создать учетные записи у поставщиков услуг, обновить предварительно настроенные параметры, а также перекомпилировать мобильные приложения с вашими частными сертификатами.
Настройка завершена, и ваше рабочее пространство готово, теперь надо нажать Go to your workspace (Перейти в рабочее пространство)
Вот так оно выглядит.
Шаг 3: Настройка обратного прокси для Rocket.Chat
Обратный прокси-сервер, например nginx или Apache, позволяет настроить приложение Rocket.Chat для доступа через домен или поддомен. Rocket.Chat является сервером приложений среднего уровня, который не поддерживает SSL/TLS. Обратный прокси-сервер позволит настраивать сертификаты SSL/TLS для включения HTTPS.
Обратный прокси Nginx для Rocket.Chat
Сначала установите Nginx.
$ sudo apt apt install nginx #Ubuntu/Debian
$ sudo dnf install nginx #Fedora 22+/CentOS/RHEL 8
$ sudo yum install nginx #CentOS/RHEL 7
Далее запустите службу Nginx, включите ее автоматический запуск при загрузке системы и проверьте ее статус
$ sudo systemctl enable --now nginx
$ sudo systemctl status nginx
Затем создайте block файл виртуального сервера для приложения Rocket.Chat, например, в каталоге /etc/nginx/conf.d/.
$ sudo vim /etc/nginx/conf.d/chat.merionet.com.conf
Далее вставьте конфигурацию в этот файл, заменив домен на свой и сохраните.
upstream backend {
server 127.0.0.1:3000;
}
server {
listen 80;
server_name chat.merionet.com;
# You can increase the limit if you need to.
client_max_body_size 200M;
error_log /var/log/nginx/chat.merionet.com.log;
location / {
proxy_pass http://backend/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forward-Proto http;
proxy_set_header X-Nginx-Proxy true;
proxy_redirect off;
}
}
Наконец проверьте синтаксис и перезапустите службу Nginx.
$ sudo nginx -t
$ sudo systemctl restart nginx
Обратный прокси Apache для Rocket.Chat
Установите пакет Apache2
$ sudo apt install apache2 #Ubuntu/Debian
$ sudo dnf install httpd #Fedora 22+/CentOS/RHEL 8
$ sudo yum install httpd #CentOS/RHEL 7
Далее запустите и включите службу apache и проверьте, запущена ли она и работает.
----- В Ubuntu/Debian -----
$ sudo systemctl enable --now apache2
$ sudo systemctl status apache2
----- В CentsOS/RHEL 7/8 -----
$ sudo systemctl enable --now httpd
$ sudo systemctl status httpd
Затем создайте файл виртуального хоста для приложения Rocket.Chat, например, в каталоге /etc/apache2/sites-available/ или /etc/httpd/conf.d/.
----- В Ubuntu/Debian -----
$ sudo vim /etc/apache2/sites-available/chat.merionet.com.conf
----- В CentsOS/RHEL 7/8 -----
$ sudo vim /etc/httpd/conf.d/chat.merionet.com.conf
Далее вставьте конфигурацию в этот файл, заменив домен на свой и сохраните.
<VirtualHost *:80>
ServerAdmin admin@merionet.ru
ServerName chat.merionet.com
LogLevel info
ErrorLog /var/log/chat.merionet.com_error.log
TransferLog /var/log/chat.merionet.com_access.log
<Location />
Require all granted
</Location>
RewriteEngine On
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteRule /(.*) ws://localhost:3000/$1 [P,L]
RewriteCond %{HTTP:Upgrade} !=websocket [NC]
RewriteRule /(.*) http://localhost:3000/$1 [P,L]
ProxyPassReverse / http://localhost:3000/
</VirtualHost>
В Ubuntu и Debian включите необходимые модули apache2 и перезапустите службу.
$ sudo a2enmod proxy_http
$ sudo a2enmod proxy_wstunnel
$ sudo a2enmod rewrite
$ sudo systemctl restart apache2
В CentOS/RHEL и Fedora перезапустите службу apache.
# systemctl restart httpd
Теперь откройте браузер и введите ваш настроенный адрес и приложение Rocket.Chat станет доступно через ваш домен, настроенный на прокси-сервере.
http://chat.merionet.com
Шаг 4: Установка клиентов Rocket.Chat
Клиентские приложения можно скачать с официального сайта Rocket.Chat. Чтобы установить десктопное приложение в Linux, вы загрузите пакет deb (x64) или rpm (x64) в зависимости от вашего дистрибутива Linux.
$ wget -c https://github.com/RocketChat/Rocket.Chat.Electron/releases/download/2.17.7/rocketchat_2.17.7_amd64.deb
Или
$ wget -c https://github.com/RocketChat/Rocket.Chat.Electron/releases/download/2.17.7/rocketchat-2.17.7.x86_64.rpm
Затем установите пакет с помощью диспетчера пакетов dpkg или rpm
$ sudo dpkg -i rocketchat_2.17.7_amd64.deb #Ubuntu/Debian
$ sudo rpm -i rocketchat-2.17.7.x86_64.rpm #CentOS/RedHat
Ручная установка Rocket.Chat
Если вы не хотите устанавливать Rocket.Chat через Snaps, вы можете сделать это вручную.
Установка Node.js
Сначала обновите список системных пакетов:
sudo apt update
Установите Node.js, npm и все другие зависимости, необходимые для сборки пакетов npm из исходного кода:
sudo apt install nodejs npm build-essential curl software-properties-common graphicsmagick
Мы будем использовать n, пакет npm, который позволяет интерактивно управлять версиями Node.js. Выполните команды ниже, чтобы установить n и Node.js:
sudo npm install -g inherits n
sudo n 8.11.3
Установка MongoDB
MongoDB - это документно-ориентированная база данных NoSQL, которая используется Rocket.Chat для хранения данных.
Импортируйте открытый ключ MongoDB и включите официальный репозиторий MongoDB:
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 9DA31620334BD75D9DCB49F368818C72E52529D4
sudo add-apt-repository 'deb [arch=amd64] https://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.0 multiverse'
После включения репозитория apt обновите список пакетов и установите MongoDB, набрав:
sudo apt update
sudo apt install mongodb-org
Затем включите и запустите службу MongoDB:
sudo systemctl start mongod
sudo systemctl enable mongod
Создание нового системного пользователя
Теперь необходимо создать нового пользователя и группу с именем rocket, которые будут запускать инстанс Rocket.Chat.
sudo useradd -m -U -r -d /opt/rocket rocket
Добавьте пользователя www-data в новую группу пользователей и измените права доступа к каталогу /opt/rocket, чтобы Nginx мог получить доступ к установке Rocket.Chat:
sudo usermod -a -G rocket www-data
sudo chmod 750 /opt/rocket
Установка Rocket.Chat
Переключитесь на пользователя rocket
sudo su - rocket
Загрузите последнюю стабильную версию Rocket.Chat с помощью curl:
curl -L https://releases.rocket.chat/latest/download -o rocket.chat.tgz
После завершения загрузки извлеките архив и переименуйте каталог в Rocket.Chat:
tar zxf rocket.chat.tgz
mv bundle Rocket.Chat
Перейдите в каталог Rocket.Chat/programs/server и установите все необходимые пакеты npm:
cd Rocket.Chat/programs/server
npm install
Чтобы протестировать нашу установку перед созданием модуля systemd и настройкой обратного прокси с Nginx или Apache, мы установим необходимые переменные среды и запустим сервер Rocket.Chat
export PORT=3000
export ROOT_URL=http://0.0.0.0:3000/
export MONGO_URL=mongodb://localhost:27017/rocketchat
Вернитесь в каталог Rocket.Chat и запустите сервер Rocket.Chat, введя следующие команды:
cd ../../
node main.js
Если ошибок нет, вы должны увидеть следующий вывод:
? +---------------------------------------------+
? | SERVER RUNNING |
? +---------------------------------------------+
? | |
? | Rocket.Chat Version: 0.71.1 |
? | NodeJS Version: 8.11.3 - x64 |
? | Platform: linux |
? | Process Port: 3000 |
? | Site URL: http://0.0.0.0:3000/ |
? | ReplicaSet OpLog: Disabled |
? | Commit Hash: e73dc78ffd |
? | Commit Branch: HEAD |
? | |
? +---------------------------------------------+
Остановите сервер Rocket.Chat с помощью Ctrl+C и вернитесь к своему пользователю sudo, набрав exit.
Создание модуль Systemd
Чтобы запустить Rocket.Chat как службу, нужно создать файл модуля rocketchat.service в каталоге /etc/systemd/system/.
sudo nano /etc/systemd/system/rocketchat.service
Вставьте следующий код:
[Unit]
Description=Rocket.Chat server
After=network.target nss-lookup.target mongod.target
[Service]
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=rocketchat
User=rocket
Environment=MONGO_URL=mongodb://localhost:27017/rocketchat ROOT_URL=https://chat.merionet.com PORT=3000
ExecStart=/usr/local/bin/node /opt/rocket/Rocket.Chat/main.js
[Install]
WantedBy=multi-user.target
Сообщите systemd, что мы создали новый файл модуля, и запустите службу Rocket.Chat, выполнив:
sudo systemctl daemon-reload
sudo systemctl start rocketchat
Проверьте статус сервиса:
sudo systemctl status rocketchat
Вывод должен быть таким:
* rocketchat.service - Rocket.Chat server
Loaded: loaded (/etc/systemd/system/rocketchat.service; disabled; vendor preset: enabled)
Active: active (running) since Wed 2018-11-07 14:36:24 PST; 5s ago
Main PID: 12693 (node)
Tasks: 10 (limit: 2319)
CGroup: /system.slice/rocketchat.service
`-12693 /usr/local/bin/node /opt/rocket/Rocket.Chat/main.js
Наконец, включите автоматический запуск службы Rocket.Chat во время загрузки:
sudo systemctl enable rocketchat
Готово, мы установили Rocket.Chat вручную, теперь можно переходить к настройке обратного прокси и инициализации системы, которые были описаны начиная с шага 3.
Итоги
В этом руководстве вы узнали, как установить Rocket.Chat в Linux и как настроить Nginx и Apache в качестве обратного прокси.
Чтобы узнать больше о Rocket.Chat посетите страницу документации.
В интернете можно найти множество статей с описанием шаблонов масштабирования баз данных (БД), но, в основном, это разрозненная информация с перечислением методик и практически без объяснений.
Ниже приведено подробное руководство по шаблонам масштабирования БД, пошаговым объяснением принципов их работы и примерами использования.
Практический пример
Предположим, вы создали стартап, который предлагает совместные поездки по дешевой цене. Вы выбрали город для поездок, а первая реклама привлекла не более 10 клиентов.
Вы храните информацию обо всех клиентах, поездках, местах, бронированиях и историях заказов в одной и той же БД и, скорее всего, на одной физической машине. У вас нет навороченного кеширования или конвейера обработки больших данных, ведь ваше приложение только появилось. На данный момент это – идеальный вариант: в базе мало клиентов, и система, вряд ли, бронирует по поездке каждые 5 минут.
Но время идет. В вашей системе регистрируется все больше людей, ведь это самый дешевый сервис на рынке. Да и реклама сделала свое дело. Вы получаете по 10 заказов в минуту. Постепенно это количество увеличивается до 20, а затем и 30 бронирований в минуту.
В этот момент вы замечаете, что система начинает тормозить: время отклика API сильно увеличилось, а некоторые транзакции блокируются или зависают и, в конечном итоге, не проходят. Время ответа приложения также увеличилось, что вызвало недовольство клиентов. Как же решить эту проблему?
Шаблон №1 – оптимизация запросов и реализация пула соединений
Первое решение, которое приходит на ум: кэш слишком часто использует нединамические данные (история бронирования, история платежей, профили пользователей и т.д.). Но прикладным уровнем кеширования вы не сможете решить проблему с временем отклика API, предоставляющим динамические данные (текущее местоположение водителя, ближайшая машина для конкретного клиента, текущая стоимость поездки после выхода на маршрут и т.д.).
Вы приходите к выводу, что база данных слишком нормализована, поэтому вы решаете ее немного «разбавить» и добавляете несколько избыточных столбцов (такие столбцы часто попадают в операторы WHERE или JOIN ON в запросах). Это сокращает количество запросов на соединение, разбивает большие запросы на несколько маленьких и добавляет их результаты на прикладной уровень.
Можно заняться и параллельной оптимизацией – настроить подключения к базам данных. Внешние и клиентские библиотеки БД доступны практически для всех языков программирования. Для кеширования подключений к БД можно воспользоваться библиотеками пула соединений. Либо вы можете настроить размер пула соединений в самой СУБД.
Создание сетевого подключения – вещь весьма затратная, поскольку требует двусторонней коммуникации между клиентом и сервером. Пулы соединений помогают оптимизировать количество подключений. Библиотеки пула соединений реализуют мультиплексирование подключений – несколько потоков приложения могут пользоваться одним и тем же подключением.
Вы замеряете время отклика API и замечаете снижение задержки на 20-50% (или даже больше). На данный момент это хорошая оптимизация.
Затем вы расширили бизнес на еще один город и получили больше клиентов. Постепенно вы доходите до 80-100 бронирований в минуту. Ваша система не в состоянии справиться с таким объемом. Вы вновь замечаете увеличение времени ожидания API, а слой базы данных не справляется с нагрузкой. Но в этот раз оптимизация запросов не дает вам существенного улучшения производительности. Вы проверяете метрики системы и видите, что дисковое пространство заполнено, ЦП занят в 80% времени, а ОЗУ переполняется слишком быстро.
Шаблон № 2 – вертикальное масштабирование или масштабирование вверх
Изучив все системные метрики, вы не находите другого решения, кроме как обновить аппаратное обеспечение системы. Вы увеличиваете размер оперативной памяти в 2 раза, а объем диска – раза в 3. Это называется вертикальным масштабированием. Вы сообщаете группе по обслуживанию инфраструктуры, команде devops или агентам сторонних центров обработки данных (ЦОД) о необходимости обновления вашей машины.
Но как настроить саму машину для вертикального масштабирования?
Вы выделяете машину большего объема. Один из подходов заключается в том, чтобы не переносить данные со старой машины вручную, а настроить новую машину в качестве копии, или реплики (replica), уже существующего устройства, или источника (primary), прописав временную конфигурацию первичной реплики (primary replica). После завершения репликации назначьте новую машину в качестве primary и отключите старую. Поскольку обрабатывать запросы планируется на этой новой машине, все чтение/запись также будет вестись на ней.
Отлично. Вы прокачали систему, и теперь все работает намного быстрее.
Ваш бизнес идет на ура, и вы решаете расшириться еще до 3 городов. Теперь вы ведете деятельность в 5 городах. Трафик увеличился втрое, вы получаете по 300 заказов в минуту. Проблема с производительностью вернулась: размер индекса сильно сказывается на памяти, базу данных необходимо постоянно поддерживать, а сканирование таблицы с индексом замедлилось до невозможности. Вы подсчитали стоимость дальнейшего масштабирования системы, но цена не внушает доверия. Так что же делать?
Шаблон №3 – разделение ответственности на команды и запросы (CQRS):
Вы понимаете, что та самая большая машина не в состоянии обработать все запросы на чтение/запись. Да и чаще всего компаниям нужны транзакционные возможности на запись (write), а не чтение (read). Вас даже устраивает небольшая несогласованность данных или замедление операций read. В принципе, раньше это тоже не казалось вам проблемой. Вы решаете, что неплохо было бы разделить операции чтения и записи на физической машине. Это позволит отдельным машинам выполнять больше операций чтения/записи.
Теперь вы берете целых 2 большие машины и настраиваете их репликами для текущего компьютера. Репликация базы данных решит вопрос с переносом данных с primary машины на реплики. Вы перенаправляете все запросы на чтение (буква Q в CQRS, что означает «запрос» - Query) в реплики – любая реплика может обслуживать любой запрос на чтение. А все запросы на запись остаются на первичной машине. Возможна небольшая задержка в репликации, но в вашем конкретном случае это не критично.
Вариант с настройкой primary-replica вполне подходит для большинства стартапов среднего масштаба, получающих по сотням тысяч запросов ежедневно… но при условии, что компании периодически архивируют старые данные.
Вы вновь расширились на 2 города, и замечаете, что primary-машина не справляется со всеми запросами на запись. Многие такие запросы приходят с опозданием. Более того, задержка между primary и replica начинает сказываться на клиентах и водителях. Например, поездка завершена, клиент успешно ее оплачивает, но водитель не видит платеж, поскольку активность клиента – это запрос на запись, который идет на машину primary, а активность водителя – это запрос на чтение, который приходит на одну из реплик. Вся система настолько замедлилась, что водитель не видит платежа как минимум секунд 30, и это вызывает недовольство как со стороны клиента, так и у самого водителя. Как же поступить сейчас?
Шаблон №4 – репликация с несколькими источниками
Конфигурация primary-replica помогла вам успешно масштабироваться, однако теперь для операций записи не хватает возможностей. Быть может, вы согласитесь слегка пожертвовать быстротой запросов на чтение. А почему бы не перенести запросы на запись тоже в реплики?
В модели с несколькими источниками (multi-primary) все машины работают как источник, и как реплика. Такая структура чем-то напоминает замкнутый круг из машин: A->B->C->D->A. «B» может реплицировать данные из «A», «C» – реплицирует данные из «В», «D» – дублирует данные из «C», а «A» делает тоже самое из «D». Вы можете выполнять операцию чтения и одновременно записывать данные в любой узел; вы можете транслировать запрос во все узлы, а значение вернет один из откликнувшихся узлов. Все узлы имеют одинаковую схему БД, один и тот же набор таблиц, индекс и т.д. Но нужно следить, чтобы в узлах одной таблицы не было конфликта по id , иначе при трансляции запросов несколько узлов вернут разные данные по одному и тому же id.
Вообще считается, что для ID лучше использовать UUID или GUID. Еще один недочет данной системы: из-за трансляции запросов и поиска корректного результата, запросы на чтение могут оказаться неэффективными. Это, своего рода, принцип распределения/сборки в действии.
И вот вы вновь масштабировали бизнес. В этот раз на 5 новых городов. Система не справляется. Теперь вам нужно обрабатывать по 50 запросов в секунду. Вам очень не хватает обработки большого количества параллельных запросов. Но как это сделать?
Шаблон №5 – декомпозиция
Вы знаете, что база данных location получает много трафика на чтение/запись. Вполне возможно, что соотношение записи к чтению составляет 7:3. Это создает большую нагрузку на существующие БД. В таблицах location содержится несколько первичных данных: долгота (longitude), широта (latitude), отметка времени (timestamp), ID водителя (driver id), ID поездки (trip id) и т.д.
Там практически нет информации о поездках или данных пользователя, его платежах и т.д. Возможно, стоит разделить таблицы location на отдельную схему? Как насчет того, чтобы распределить эту БД по отдельным машинам с корректно настроенной конфигурацией primary-replica или multi-primary?
Это называется декомпозицией данных по функциональности. В разных БД можно хранить данные, разделенные по функциональному признаку, а результат (при необходимости) агрегируется на серверном уровне. Такой способ позволит вам масштабировать нужный функционал с большим количеством запросов на чтение/запись. В то же время прикладной или серверный уровень приложения должен будет заняться объединением результатов, что приведет к значительному изменению кода.
Теперь представьте себе, что вы масштабировались до 20 городов в своей стране и планируете открыть филиалы в Австралии. Растущий спрос на ваше приложение требует все более быстрого времени ответа. Ни один из методов выше с этим не поможет. Вам нужно масштабировать систему так, чтобы при расширении в другие страны/регионы не приходилось слишком часто проектировать и менять архитектуру. Как же тогда поступить?
Шаблон №6 – горизонтальное масштабирование
Вы хорошо загуглили эту тему, почитали массу статей о том, как другие компании решали такую проблему, и поняли, что настал момент масштабироваться горизонтально. Вы выделили, скажем, 50 машин – все с одинаковой схемой БД и одинаковыми наборами таблиц. На каждой машине хранится лишь часть данных.
Поскольку во всех БД хранится один и тот же набор таблиц, вы можете спроектировать систему таким образом, чтобы реализовать привязку данных (то есть все связанные данные хранятся на одной машине). В каждой машине может быть своя реплика; реплики используются для восстановления после сбоя. Каждая такая база данных называется «шардом». На физической машине может быть один или несколько шардов – их количество зависит от нужной вам схемы проектирования. Вы должны придумать ключ шардирования, который бы всегда относился к одной и той же машине. Представьте себе много машин с кучей связанных данных в одном наборе таблиц; операции на чтение/запись запрашиваются для одной и той же строки или набора ресурсов на одной и той же машине с БД.
Реализовать шардинг довольно сложно. По крайней мере, так говорят инженеры. Но при обслуживании миллионов или даже миллиардов запросов, рано или поздно вам придется пойти на столь непростой шаг.
Настроив шардинг, вы уверены, что сможете масштабироваться во многие страны. Ваш бизнес разросся настолько, что инвесторы вынуждают вас расширяться на другие континенты. И тут опять возникают проблемы. Все то же время отклика API. Ваш сервис находится в США, и у пользователей из Вьетнама возникают трудности при бронировании. Но почему? И что же делать?
Шаблон №7 – умное сегментирование центров обработки данных
Ваш бизнес развивается в Америке, Южной Азии и нескольких странах Европы. Каждый день вы получаете миллионы заказов, а ваш сервер атакуют миллиарды запросов. Поздравляю! Это пиковый момент в вашей деятельности.
Запросы из приложения поступают с разных континентов и проходят через сотни или даже тысячи серверов в интернете, поэтому время отклика растет. Может, распределить трафик по центрам обработки данных? Вы могли бы настроить ЦОД в Сингапуре, и он бы обрабатывал все запросы из Южной Азии. Затем сделать еще один в Германии – он займется всеми запросами из европейских стран, и оставить ЦОД в Калифорнии для обработки американских запросов.
Кроме того, вам понадобится репликация между ЦОД – на случай, если потребуется восстановление после сбоя. Если центр обработки данных в Калифорнии выполняет репликацию сингапурского ЦОД, то в случае аварии в Калифорнии (стихийные бедствия, отсутствие электричества и т.д.), все запросы из США будут передаваться в Сингапур и наоборот.
Такой метод масштабирования подходит для: обслуживания миллионов клиентов из разных стран, сохранения всех данных и поддержания постоянной доступности системы.
Заключение
В статье приведены общие методы по масштабированию базы данных. Стоит сказать, что у большинства инженеров нет достаточных возможностей для реализации всех шаблонов. Но лучше знать о существовании таких схем, которые в будущем могут помочь вам с проектированием архитектуры и систем.