Поможете сформировать правильно структуру БД?

Question

[lamer350]

Не могу придумать как минимизировать количество записей в БД (utf-8).
Математика следующая:
имеется 1 млн страниц на сайте (id - 10 знаков)
имеется 1 млн пользоватлей на сайте (зарегестрованных)
Каждому пользователю выводим РАНДОМНО страницу, больше он ее не должен увидеть. Если я правильно посчитал, что приближаясь к миллиону просмотренных страниц - сохраняя только id, получится набор данных примерно 200кб на каждого пользователя.
При выводе новой страницы для пользователя нужно проверить смотрел он ее или нет, тоисть подгружается массив данных в 200кб... при нагрузке 30к пользователей на сайте: требуется 6 гиг RAM только на обработку этих запросов...
Как можно изменить логику структуры БД?
Была идея разбивать на таблицы где id 0-50тис, 50-100, 100-150 и тд, таким образом при генерации числа проверяли в каком диапазоне лежит число и обращались нужную таблицу для проверки смотрел ли пользователь страницу с таким id, таким образом масив бы был уже не 200кб, а максимум 10...
А вторая идея - выгружать данные в кеш пользователя при первой генерации, и работать уже с кешем. Хранить все только в кеш нельзя, так как регистрация для того и создана - чтоб можно было заходить с разных устройств.
Но возможно я изобретаю велосипед и все это придумано уже давно. Поделитесь опытом, ссылками и советами. спасибо.

Answer 1

[Anatoly Scherbakov]

Не понимаю, должен признаться... Пусть есть таблицы User и Page, сохраняем для каждого пользователя список страниц, которые он уже видел. Сделаем таблицу View с колонками:

• user - id пользователя,
• page - id страницы,
• time - время просмотра.

Чтобы просмотреть миллион страниц из расчёта секунда на страницу пользователю потребуется 1000000/3600 = 277.77 часов = 11.5 суток непрерывного просмотра = 34.7 суток просмотра из расчёта 8 часов в день, 7 дней в неделю. Не видел случаев, когда такое нужно, ну да ладно; вам виднее. Ну и пусть в этой таблице будут миллионы записей, и что? Вы можете использовать partitioning, - MySQL его поддерживает.

Что касается выборки очередной страницы для просмотра: зачем вам загружать это всё в память? Это делается средствами SQL (если выборка страницы действительно случайна).

И потом, вам действительно надо случайную выборку или можно показывать страницы просто по порядку? Без понимания предметной области это не понятно.

Comments

[lamer350]

Ну я цыфры назвал с запасом, чтоб потом не переделывать. Пользователю на просмотр страницы нужно от 1 до 20 сек. Но не в этом дело. Вся суть сервиса именно в рандомной генерации страниц, потому по порядку показать не получится. А данные все в память загружать, так как мои мысли немного отличались от ваших, так как вы предлагаете сделать таблицу view c 1 000 000 000 000 строк, не будет ли это тяжелее обработать чем 1 000 000 строк? Я думал что легче будет создать одну строку с id пользователя в таблице view, а id страниц добавлять в одно поле медотодом update, таким образом будет получатся один массив с id страниц (при запросе в базу).
Если я правильно понял, вы предлагаете сделать одну таблицу и каждую просмотренную страницу делать отдельной строкой в базе, но при этом просто разбить данные на секторы?

[Anatoly Scherbakov]

Именно так. В этом случае выборка очередной страницы делается одним SQL-запросом. Как построить этот запрос и индексы для него - сходу не подскажу, я не специалист по SQL; но убеждён, что сделать это можно.

[lamer350]

Anatoly Scherbakov: Спасибо! Буду пробовать так сделать!