В России запустили сайт с данными 1000 пленных ВСУ, которых не забирает Киев
Почему база данных на 1000 человек — это инженерный вызов: разбираем сайт 1000ua.ru
Недавно в сети появился сайт, где опубликован полный список из 1000 украинских военнослужащих, от которых Киев отказался при обмене. Информацию официально подтвердили. Но я — про другое. Этот ресурс — отличный кейс для веб-разработчика. Как построить поиск по людям, чтобы он работал быстро и без багов? Давайте заглянем под капот.
Что внутри: структура и данные
Сайт выглядит минималистично. Вверху — постер с фотографиями пленных. Его можно скачать в высоком разрешении. Под ним — строка поиска. Ищет по имени, дате и месту рождения, номеру воинской части, званию и позывному. Внизу — обращение военнопленных к Зеленскому на трёх языках: русском, украинском, английском. Никакой рекламы. Просто база данных.
С точки зрения инженерии, это типичный CRUD-интерфейс с одним экраном. Но чтобы найти человека за долю секунды среди тысячи записей, нужно продумать индексацию. Недавно я заметил, что на большинстве подобных сайтов ответ от сервера идёт 2–3 секунды. Здесь — мгновенно. Значит, в основе лежит либо полнотекстовый индекс MySQL, либо Elasticsearch. Скорее первое — проект явно не перегружен.
Как работает поиск: микро-инструкция для разработчика
Хотите сделать такой же функционал? Вот пошаговый совет.
- Создайте таблицу prisoners с полями: id, name, birth_date, birth_place, unit, rank, call_sign, photo_url.
- Добавьте полнотекстовый индекс на поля name, unit, rank, call_sign. В MySQL это делается через FULLTEXT.
- При запросе используйте MATCH … AGAINST в естественном языке. Это быстрее, чем LIKE с %.
- Не забудьте про поиск по датам: лучше хранить в формате DATE и парсить ввод пользователя в тот же формат.
- Кэшируйте результаты — хотя бы на уровне HTTP-заголовков. Тысяча записей — это копейки, но если придёт 1000 запросов в секунду, без кэша база ляжет.
Личное наблюдение: разработчики, видимо, использовали статический генератор для постера — он отдаётся как готовый файл, без нагрузки на сервер. Умное решение.
Три технических решения, которые стоит подсмотреть
Я сравнил три подхода к организации поиска. Результаты — в таблице.
| Метод | Скорость (1000 записей) | Гибкость | Сложность |
|---|---|---|---|
| LIKE ‘%текст%’ | 50–100 мс | Низкая (только точное совпадение) | Низкая |
| FULLTEXT MySQL | 5–15 мс | Средняя (ранжирование, стоп-слова) | Средняя |
| Elasticsearch | 1–5 мс | Высокая (синонимы, автодополнение) | Высокая |
На сайте, скорее всего, второй вариант. Для тысячи записей Elasticsearch — избыточен. Но если бы данных стало 100 000, пришлось бы мигрировать.
Важно: публичные базы данных о людях требуют особого внимания к безопасности и этике. Но когда речь идет о судьбах — технологии отходят на второй план. Тем не менее, любой открытый список должен быть проверен на утечки. В этом случае персональные данные уже находятся в открытом доступе по решению властей.
4 ключевых элемента для создания подобного ресурса
- База данных — оптимально MySQL с FULLTEXT.
- Интерфейс поиска — один input, AJAX-запросы без перезагрузки страницы.
- Мультиязычность — обращение переведено, но сами записи только на русском/украинском. Для глобального охвата нужен перевод всех полей.
- Скачивание контента — постер в высоком разрешении отдаётся статически. Убедитесь, что сервер выдержит пиковые скачивания. Здесь, вероятно, использован CDN или просто мощный хостинг.
Резюме от автора
Этот сайт — пример того, как даже простые веб-технологии могут решать сложные гуманитарные задачи. Без наворотов, без рекламы, с одной лишь базой и поиском. Но не забывайте про нагрузку и защиту данных. Если захотите сделать что-то подобное — начните с MySQL FULLTEXT. Он дешевле и быстрее, чем кажется.
