Noder SS

Используйте заголовки безопасности HTTP
https://kostikov.co/post/zagolovki-http-i-bezopasn...

В дефолтный домен (конфиг Nginx) добавьте секцию HTTPS. И соответственно открываться должна заглушка.
Иначе, все кто ссылаются на ваш IP будут считаться Яндексом зеркалами домена, на который выдан сертификат.
Буквально на неделе с такой проблемой ко мне обращались.

Воспользуйтесь шаблонизатором, ejs например

span + https://developer.mozilla.org/en-US/docs/Web/CSS/g...
Если поиграться с параметрами - можно попробовать добиться нужного эффекта.

Если по простому:

border-bottom: 3px solid blue;
background: #d4e5ff;

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

Отличный пример - числовое ключевое поле с монотонным ростом без пропусков позволяет использовать самый простой индексный файл где значение ключевого поля это смещение слова (например 4 байта) в индексном файле, а эти слова - это смещение в файле данных (например номер кластера фс, данные выровнены по нему). Файл данных это тупая последовательность размер+данные без разделителя.

Достоинства - максимальная из возможных производительность (файл данных и индексный файл могут храниться без файловой системы прямо в блочных устройствах), буквально 2 запроса на запись/поиск (при использовании файловых систем операций будет в несколько раз больше), ни одна универсальная база данных не даст такой. Кода - строк 20-30 на любом языке программирования, красиво можно пользоваться memory mapped files (они дают самую быструю работу с файлами и удобную под задачу). Данные пишутся линейно на диск (оптимально для hdd, само собой если не одновременно с чтением), большинство файловых и операционных систем поддерживают sparce файлы (будут накладные расходы, но константа), это значит можно с некоторыми оговорками пользоваться большими пропусками в порядке индексов (дырка в файле вернет нули, на диске храниться не будет).

Недостатки/особенности - требуется некий роутер, для управления несколькими файлами, если размер данных может выходить за пределы имеющихся устройств (в реляционных базах данных для этого есть прозрачный механизм tablespace), но на практике красивых монотонных индексов не существует и приходится выкручиваться, например группировать данные

Пример - временной ряд, в секунду происходят тысячи событий, хранить группами по секунде, т.е. ключевое поле для индекса - это timestamp-стартовое время файла, при среднем размере информации о событии в 100байт и 4 тысячи событий в секунду, на 3терабайтовый диск hdd индексы будут порядка 30 мегабайт, что прекрасно влезает в оперативную память. У меня самый дешевый toshiba3тб выдавал 60 req/sec случайных запросов (как в синтетических бенчмарках), при этом запрашивать можно было сразу большими интервалами, что роняло скорость максимум в 2-3 раза, пока данные влезали на дорожку (в зависимости от расположения там по разному). Последовательное чтение данных само собой работало на максимуме скорости диска в 150-200мб/с.
p.s. от такой модели отказался за ненадобностью, данные хорошо упаковывались большими блоками (в 10 раз), храню теперь просто в архивах большими блоками по несколько часов, на время работы нужные данные переливаются во временные файлы.

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

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

В моём случае руководитель пошёл на встречу: я устроился на полставки (20 часов в неделю) + работа дистанционно.

Так что главное 1) решить что важно для тебя, 2) уметь договариваться.

можно. только тогда зачем учиться? а темболее ходить в универ на пол дня?)

Несколько мыслей.

1) У меня устойчивое дежа-вю. Периодически в топик заходят люди с именно этим вопросом. Разница только в количестве. Кому 1 млрд. Кому 10. Можно также поискать и слинковать эти вопросы в один большой вопрос.

2) MySQL который указан в тегах - нормально справляется с этой задачей. Он и не такое число строк
умеет хранить. И если взять MariaDb - там есть куча новых engines которые можно крутить для тюнинга
именно скорости чтения. Разумеется жертвуя чем-то другим. Транзакциями и записью например.

3) Непонятно что такое минимальное время? Если использовать дисковую БД типа MySQL то деградация времени
поиска будет примерно зависеть от логарифма количества строк. Тоесть деградация будет но очень медленно.
Для 10 млрд индекс по key будет содержать порядка 4-5 уровней BTree дерева. Тоесть дисковой системе
нужно будет сделать до 5 или до 6 рандомных чтений (если нужные данные лежат в таблице). Это достаточно
быстро для того чтобы моргнуть глазом за это время. Рандомное чтение любого блока из магнитного диска
класса SATA-3 занимает порядка 20 милисекунд. Тоесть для 5 уровней - это 100 милисекунд. Для дисков
класса SSD и это время можно уже считать меньше милисекунды. Точно я не знаю надо мерять.

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

4) Непонятно зачем здесь указан Redis. Его задача не хранить 10 млрд а хранить только горячие
ключи по котороым идет очень частый доступ. Если автор хочет In-memory хранение - то время можно
еще сильнее улучшить. Его можно свести практически до нуля (я вангую несколько микро-секунд)
но придется прикупить планок памяти побольше и посчитать сколько памяти
надо для 10 млрд key/values неизвестной длины. Вообще крутить регулятор в направлении
микро-секунд нет особого смысла т.к. другие звенья вашего стека (приложение и сеть) могут
быть на порядки медленнее а это вообще нивелирует всю пользу от такой оптимизации.

Установите кодировку UTF-8 сразу после подключения, например:

$connection = new PDO('mysql:host=localhost;dbname=test',  'username', 'password');
$connection->query("SET NAMES utf8");