Производительность приложений на Bubble. Заметки. Часть 7. Оптимизация структуры БД.
Данная серия статей — это мои заметки по книге The Ultimate Guide to Bubble Performance. Тут изложено только то, что фиксировал я, т.к. посчитал это важным.
На то, как быстро Bubble может найти, скачать и предоставить нужные данные влияют 2 вещи: состав записей и размер загрузки данных.
Размер загрузки
Это размер записи в БД. Чем больше запись весит, тем дольше скачивается. И есесна занимает больше места у пользователя на устройстве после загрузки.
К примеру, есть запись из БД "Users". Мы ещё никаких филдов в неё не добавляли, всё дефолтное:
Если мы захотим загрузить 10к таких записей, то скачиваемый размер увеличится до 1.6 мегайбат.
А теперь добавим пользователю поля "First name", "Last name" и "Phone number"
Теперь 1 запись весит 191 байт. На 10к записей приходится 1.8 мегабайт.
А теперь добавим пользователю поле "Article".
Теперь размер увеличился до 5.5 килобайт на 1 запись пользователя. Если мы попытаемся загрузить 10к записей, то скачиваемый размер получится 55 мб, что уже нихуясебе.
Естественно, когда мы загружаем данные, то в большинстве случаев предварительно их фильтруем, чтобы Bubble отдал нам только нужное.
Важный момент: Bubble грузит всю информацию по запрашиваемой записи, даже если часть информации не отображается на экране. То есть, если бы я захотел отобразить только Имя и Фамилию, статья бы тоже подтянулась и скачиваемый размер был бы равен не 191 байт, а 5.5 кб.
Состав записи
Подразумевает количество полей в вашей записи и тип данных, который они содержат (text, date, number и т.д.)
Контент в каждом поле записи влияет на то, как быстро бабл будет соображать при обработке этой записи.
Поля в записях разделяются на несколько типов по нагрузке: легкие, средние и тяжёлые.
Это те, которые нагружают Bubble крайне слабо. Это такие поля как Имя, Фамилия, Дата Рождения и т.д.
Поиск с использованием подобных полей быстрый.
Помните мы добавили поле с типом данных "Article"?
Это поле содержит в себе мнооого строчек текста. Если мы будем искать пользователя, у которого лежит какая-то определенная статья, то для Bubble это будет уже нагрузкой посерьёзнее, чем поиск по Имени.
Потому что Bubble нужно будет перебрать огромное количество текста, прежде чем он найдёт точное совпадение.
Тяжёлые поля - это те, который содержат списки.
Например, хочу отслеживать пользователей, которые прочли мою статью. Поэтому я добавляю филд "Reader" (list) в Article. Туда буду складывать всех пользователей, которые прочитали статью.
Теперь Bubble при поиске статей для каждой из них будет загружать список пользователей из "Reader". Потенциально, это могут быть тысячи пользователей.
Подобные поля со списками влияют не только на скорость поиска, но и в целом на то, какое количество данных Bubble должен обработать, прежде чем передать данные с сервера клиенту. И даже когда данные будут переданы, они займут огромное место в ОЗУ клиента. Если у нашей статьи тысячи читаталей, то все они будут загружены в ОЗУ и могут запустить в космос клиентское устройство.
Надеюсь, распаковал материал доступно.
→ Подписывайтесь на мой канал в Телеграме Иван Некодит.