January 11

Миллиард записей

В фильмах часто бывают смешные моменты. Какая-то база данных преступников. Ну сколько там записей, ну максимум миллион и то если действие происходит в большой стране. И начинается медленный поиск, герои напряженно смотрят на экран, а там зачем-то мелькают картинки. Пролетают секунды, минуты, поиск все идет, хотя на самом деле результат должен быть получен мгновенно...

А еще у меня начал тормозить телефон во время поиска по контактам. Сколько записей там, 200-300, не больше. Что это такое и кто виноват (Линукс, Андройд, сбои памяти, жадные производители искусственно замедляющие скорость), неизвестно.

Поведаю вам одну историю из реального мира эксплуатации средних по размеру систем на 1С. Распределенная база, 300 филиалов, были включены обмены с каждым. Потом, как обычно, попрыгунчики смылись, дела не передали, следующая команда филиалы отвязала, а настройки планов обмена не удалила. И вот, когда и они разбежались в другие места, база данных зажила своей жизнью. В итоге, в таблице изменений регистра "Номенклатура сегментов" накопился миллиард ненужных записей (тупо автоматически готовились данные для выгрузки в каждый филиал и никогда не выгружались). При этом база использовалась как веб-сервис скидок и работала быстро и устойчиво. Это я к тому, что современное железо позволяет приемлемо работать даже с избыточно большими объемами информации. Не верьте фильмам.

В связи с этим мне непонятно, зачем хешировать базу телефонов покупателей из программы лояльности при передаче различным банкам. Чтобы что? Чтобы если перехватили хеши, не смогли определить телефоны? Но ведь телефонных номеров начинающихся с "+79" всего миллиард (точнее 999 999 999). Это же очень мало. Можно построить полную базу вместе с хешами, а потом по перехваченным хешам получить сами телефоны. Получается, в этом случае защита является иллюзорной.

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

←19 | заметка 20 | 21→