• Как настроить PostgreSQL, на блокировку БД, в случае превышения количества неправильных вводов пароля?

    @os9
    DFalco,
    Каковы требования, таковы и реализующие.
    Можете попробовать команду форматирования диска выполнять, когда надо заблокировать БД.
  • Как правильно хранить такие данные?

    @os9
    Егор Скороходов,

    1. Просто для понимания - а что за текстовые 2 тыс. полей у вас, по которым требуется агрегация по всем пользователям? Когда числовые признаки, то можно считать сумму, кол-во ненулевых и т.д. А по строкам какая будет агрегация?

    2. Если действительно агрегация по всем пользователям, и нужна только часть полей, то смотрите в торону columnstore на любой СУБД. Такие таблицы умеют хорошо сжимать данные в столбцах, и за счет компактного хранения агрегация происходит быстрее.

    3. Но сначала можно попробовать упомянутую тут модуль EAV на реляционной СУБД, только нужно продумать, как организовать хранение. Наверно, кластерный индекс будет по (ИД Свойства, ИД Пользователя), чтоб при выборке по одному "ИД Свойства" по всем пользователям у вас нужные данные оказывались более компактно расположены на страницах, т.е. требовалось бы меньшее количество чтений.
    Этот опыт вы можете легко поставить. Результат зависит от вашего железа, реальных объемов, количества выбираемых свойств пользователя.
  • Как правильно хранить такие данные?

    @os9
    Требуется высокая гибкость выборок.

    Опишите, какие именно выборки ожидаются. По одному пользователю, по 100, агрегация по всем 1 млн? Также, все поля о пользователе нужны всегда или только часть?

    при миллионе user и тысяче field будет равняться миллиарду. Это ведь слишком много?

    В байтах померяйте. Какая разница, в какой структуре будут лежать эти данные, если их объективно, скажем, 100 Гб. Много это или мало для вас, зависит от требований к выборкам, железа и т.д.