С точки зрения современной технологии, значимы ли эти опасения относительно размера данных?

Question

Мы добавляем дополнительную информацию для входа в существующую запись базы данных порядка 3,85 КБ на имя входа.

Есть две проблемы по этому поводу:

1) Это слишком много данных по сети добавляется за логин?

2) Это слишком много дополнительных данных, которые мы храним в базе данных для каждого логина?

Учитывая сегодняшнюю технологию, это действительные проблемы?

Справочная информация:

У нас нет конкретных цифр использования, но мы в среднем около 5000 логинов в месяц. Мы надеемся, что масштабируемся на более крупных клиентов, однако, все еще в 10 тысячах в месяц, а не 1000 в секунду.

В США (наш рынок) широкополосная связь на рынке занимает 60%.

Answer 1

Предполагая, что у вас есть ~ 80 000 логинов в месяц, вы бы добавили ~ 3,75 ГБ за ГОД в таблицу базы данных.

Если вы используете достойную СУБД, такую ​​как MySQL, PostgreSQL, SQLServer, Oracle и т. Д., То это просто смешной объем данных и трафика. Через несколько лет вы можете захотеть начать архивировать некоторые из них. Но к тому времени, кто знает, как будет выглядеть приложение?

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

Но чтобы ответить на ваше беспокойство, не беспокойтесь. Просто всегда продолжай думать.

Answer 2

Учитывая, что хранилище и аппаратные средства стоят СООО дешево в наши дни (условно говоря, конечно), это не должно быть проблемой. Очевидно, что если вам нужны данные, то вам нужны данные! Вы можете использовать репликацию в нескольких местах, так что добавленные данные не должны перемещаться по проводам так далеко (например, сервер на западном и восточном побережье). Вы можете управлять своими данными, разделяя их по состоянию, чтобы минимизировать размер таблиц (аналогично тому, что делают банки, выбирайте состояние как часть процесса входа в систему, чтобы они обращались к правильному хранилищу данных). Вы можете использовать горизонтальное разбиение, чтобы минимизировать количество или количество записей в таблице, чтобы ваши запросы были быстрыми. Множество способов оптимизировать большие данные. Также проверьте в Lucene, если вы планируете много читать эти данные.

Answer 3

Сколько у вас пользователей? Как часто они должны войти? Они могут быть на быстрых соединениях или влажных кусочках нити? Вы имеете в виду, что вы действительно добавляете 3.85K за каждый вход в систему или за учетную запись пользователя? Как долго вы должны хранить данные? Какую пользу это дает вам? Как это соотносится с объемом данных, которые вы уже храните? (т.е. большая часть ваших данных будет связана с этой новой частью, или это будет капля в океане?)

Короче говоря - это очень контекстно-зависимый вопрос:)

Answer 4

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

С точки зрения сетевого (?) Трафика, это не так много на стороне сервера, но это повлияет на скорость, с которой ваш веб-сайт загружается и функционирует для значительной части клиентов. Несмотря на то, что у многих есть широкополосный доступ, кто-то где-то попробует его на грани, на модеме или при интенсивном использовании бит-торрента, ваш сайт будет работать медленно или работать со сбоями, и вы будете получать громкие жалобы по всей сети. Это имеет значение? Если ваши пользователи действительно нуждаются в вашем сервисе, они наверняка подождут, если вы разрабатываете новый твиттер, увеличение времени загрузки страницы вряд ли приемлемо.

Answer 5

С точки зрения современной средней серверной технологии это не проблема. С точки зрения вашей серверной технологии это может быть проблемой. Вам необходимо предоставить больше информации.