• Как лучше всего хранить такой набор данных?

    Я бы не рисковал. Мой вариант безопасней.
  • Как лучше всего хранить такой набор данных?

    Лучше не рисковать с хранением в одной таблице. Хоть спецификация и допускает хранение больших объемов данных, но лучше не рисковать, где-нибудь это все равно боком обернется. И чисто из опыта говорю, что 500Мб для таблицы - это нормально даже для простенького сервера с минимальной конфигурацией железа и объемом оперативной памяти. А что может произойти при запросе SELECT из таблицы в 30Гб не могу заранее сказать. И она будет расти.

    И второй момент - у таблицы будет индекс. До определенного момента СУБД MySQL при запросах SELECT держит этот индекс в оперативной памяти (т.е. вся таблица ID помещается в оперативную память) и поиск производит в ней, это значительно повышает скорость. А если индекс не помещается, СУБД начинает скидывать его блоками на диск и искать уже поблочно. Это сильно замедляет скорость выполнения запроса. Что может приводить к зависанию всего сервера и простою других запросов в очереди.

    Поэтому наращивать базу таблицами - более безопасный вариант. По аналогии как и с файловой системой. Достаточно рисковано хранить 50 тыс файлов в одной папке, т.к. обязательно найдутся какие-нибудь программы (проводник Windows, файловый менеджер, которые от такого количество могут "захлебнуться" просто от одного только открытия этой папки на просмотр). Поэтому стараются файлы разбивать по какому-то признаку, например в хронологическом порядке /2021/03, /2021/04 и т.д. Ну зависит от прироста. Если каждый месяц добавляется порядка 1000 файлов, то разбиваем помесячно. Если в год 1000 файлов, то по годам. Если хронологии нет, то разбивается по другому признаку или просто по максимальному количеству в каждой папке.

    Запросы INSERT в большой таблице так же начнут тормозить. Т.к. чем длиннее индекс, тем дольше его придется перестраивать после каждой вставки.
  • Как подключить клиентов SIP, находящихся за NAT?

    @aleksmir Автор вопроса
    Фокс Йовович, адрес сервера Awaya - 10.0.0.2. К сети подключен роутер Asus RT-N12 через порт WAN со статическим адресом 10.0.0.3. На роутере включен NAT и DHCP, которые создают подсеть 192.168.0.0/24. Внутри подсети подключен IP-телефон клиента, имеющий например адрес 192.168.0.2
  • Как подключить клиентов SIP, находящихся за NAT?

    @aleksmir Автор вопроса
    Вы имеете ввиду на сервере Windows Server поставить две сетевые карты. Одну воткнуть во внешнюю сеть, вторую во внутреннюю, и между ними настроить маршрутизацию? При этом NAT у нас отключается, будет как-бы мост, соединяющий две подсети. И тогда голос будет спокойно проходить через этот мост. Вы это имеете ввиду?
  • Как подключить клиентов SIP, находящихся за NAT?

    @aleksmir Автор вопроса
    Спасибо, про STUN почитал. Насколько я понял, раз IP-сервер в той же сети, то он мог бы сразу выполнять роль STUN-сервера. Но это в любом случае епархия хозяина сервера и я вмешаться туда не смогу.

    Проброс портов на самом деле ничего не дал. Так как из внутренней подсети сервер и так был виден без всякого проброса. И исходящий звонок и так работал. А перенаправление входящего порта с роутера на телефон ничего не улучшило.

    Если избавиться от NAT и DHCP, то придется на всех ПК в подсети менять IP на статические. Я конечно рассматривал этот вариант. Но он очень трудоемкий, т.к. количество устройств порядка 100 и + клиенты Wi-Fi со смартфонами, которым прописывание статического IP-адреса точно не подойдет.

    Значит остается только вариант проведения кабеля к каждому телефону (телефонов порядка 15). И все телефоны подключить напрямую, минуя NAT. Он тоже трудозатратный, но менее рискованный, т.к. не затронет работу остальных клиентов уже настроенной подсети.

    Ок. Спасибо за ответ.
  • Как лучше всего хранить такой набор данных?

    Файлов 50к, значит каждый файл в отдельной таблице хранить не будем, т.к. получится очень много таблиц. Файл до 10к строк - это нормально для БД, если каждую строку будем хранить в отдельной записи. Оптимальным будет хранение нескольких файлов в одной таблице. Но не всех. Поэтому всю информацию нужно разделить на несколько таблиц по какому-то признаку. Раз ежедневный прирост неизвестен, то я предполагаю, что все 50000 были созданы одномоментно. Поэтому их можно разбить чисто условно по 50 файлов в таблице на 1000 таблиц. В этом случае каждая таблица будет занимать = 50 файлов * 10к строк * 1к в строке = 500мб. Такой объем для таблицы вполне реален. Предлагаю такую структуру БД:
    `tables` - будет хранить список таблиц (поля `id`, `name`)
    `files` - будет хранить список файлов (поля `id`, `table_id`, `name`), здесь по id файла можно будет узнать id таблицы, а по ней имя таблицы
    `t_0001` - содержимое файлов первой таблицы (поля `file_id`, `line`, `text`); здесь в поле `text` хранится содержимое каждой строки, `line` - порядковый номер строки, он будет проиндексирован составным ключом PRIMARY KEY (file_id, line), можно будет по этому ключу выбрать первые или последние строки.

    Со структурой базы можно поиграться здесь через какой-нибудь клиент, например программу HeidiSQL:
    - сервер: habr.atou.ru
    - порт: 3311
    - пользователь: habr_956597
    - пароль: 9D4z3R4b
    - база данных: habr_956597

    Вот дамп базы:
    CREATE TABLE IF NOT EXISTS `files` (
      `id` int unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID файла',
      `table_id` int unsigned NOT NULL DEFAULT '0' COMMENT 'ID таблицы',
      `name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT 'Имя файла (если нужно)',
      PRIMARY KEY (`id`),
      KEY `files_table_id_index` (`table_id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='Список файлов';
    
    INSERT INTO `files` (`id`, `table_id`, `name`) VALUES
    	(1, 1, 'Имя файла 1'),
    	(2, 1, 'Имя файла 2');
    
    CREATE TABLE IF NOT EXISTS `tables` (
      `id` int unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID таблицы',
      `name` varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT 'Имя таблицы',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='Список таблиц';
    
    INSERT INTO `tables` (`id`, `name`) VALUES
    	(1, 't_0001'),
    	(2, 't_0002');
    
    CREATE TABLE IF NOT EXISTS `t_0001` (
      `file_id` int unsigned NOT NULL DEFAULT '0' COMMENT 'ID файла',
      `line` int NOT NULL DEFAULT '0' COMMENT 'Порядковый номер строки',
      `text` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci COMMENT 'Текст строки',
      PRIMARY KEY (`file_id`,`line`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='Первая таблица для хранения 50 файлов';
    
    INSERT INTO `t_0001` (`file_id`, `line`, `text`) VALUES
    	(1, 1, 'Строка 1 файла 1'),
    	(1, 2, 'Строка 2 файла 1');
    
    CREATE TABLE IF NOT EXISTS `t_0002` (
      `file_id` int unsigned NOT NULL DEFAULT '0' COMMENT 'ID файла',
      `line` int NOT NULL DEFAULT '0' COMMENT 'Порядковый номер строки',
      `text` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci COMMENT 'Текст строки',
      PRIMARY KEY (`file_id`,`line`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='Первая таблица для хранения 50 файлов';


    P.S. Я ещё прикинул, как можно быстро добавлять строки в начало файла, чтобы не перенумеровывать строки, которые ниже. Убираем у поля `line` свойство UNSIGNED (беззнаковое) и тогда при добавлении строк в начало мы будем их нумеровать в обратную (отрицательную) сторону от нуля. И тогда перенумеровать уже сохраненные строки не придется; так что все картинка сложилась; вот вам готовое решение по БД, написать клиента на PHP - это уже дело техники.