Перевод статьи https://www.amliesolutions.com/bubble/data-weight/
Вес данных - это термин Bubble, который представлен в книге The Ultimate Guide to Bubble Performance в главе о структурировании базы данных, как способ визуализировать то, как настройка типа данных может повлиять на производительность вашего приложения.
По сути, любой тип данных, содержащий больший объем данных, потребует от сервера Bubble больше времени для поиска и загрузки, что снижает производительность вашего приложения. Мы называем эти типы данных тяжелыми, т. е они имеют большой вес.
Представьте, что ваши типы данных имеют массу - чем они тяжелее, тем больше они замедляют работу вашего приложения.
Сам термин имеет интуитивно понятный смысл - мы привыкли, что большие файлы требуют больше времени для загрузки, а длинные документы требуют больше времени для поиска и база данных ничем не отличается. Но что именно увеличивает вес типа данных? Чтобы понять это, нам сначала нужно поговорить о двух других общих терминах баз данных: структурированные и неструктурированные данные.
Что такое структурированные данные?
Структурированные данные - это любые данные, которые соответствуют заданной структуре. Мы будем использовать приложение «Контакты» на вашем телефоне в качестве примера: допустим, у каждого контакта есть поле для имени, фамилии, номера телефона и дня рождения . Каждое из этих полей структурированы в том смысле , что они следуют общей схеме:- Имя / Фамилия: тип данных Text
- Номер телефона: тип данных Text
- День рождения: тип данных Date
Это поля, которые вы можете легко включить и правильно отформатировать в электронной таблице.
Структурированные данные легковесны. С текущими полями, которые мы настроили, одна запись в этом типе данных не будет содержать более 17 байтов данных.
Имя: Джон (4 байта)
Фамилия: Доу (3 байта)
День рождения: 01.01.2000 00:00 (сохраняется как 1633028845 или 10 байтов)
Если бы мы загрузили список из 1000 контактов, его общий размер составил бы всего 17 000 байт или 17 КБ - меньше, чем одно среднее изображение. Bubble добавляет немного дополнительной информации к вашему типу данных для поиска и других целей, так что это не точный размер, но для этого примера подойдет.
Итак, что произойдет, если вы добавите в микс что-то вроде фактического изображения 17 КБ, например портретной фотографии. Это вдвое больше? Что ж, имейте в виду, что файл изображения на самом деле не хранится в базе данных - только URL-адрес. Таким образом, даже добавление огромного JPG все равно добавит в базу данных лишь несколько байтов дополнительной информации (хотя загрузка файла, конечно, все еще может увеличить время загрузки вашей страницы, но это не связано с базой данных)
Когда мы добавляем неструктурированные данные, размер записей базы данных начинает расти.
Что такое неструктурированные данные?
Неструктурированные данные, как вы уже догадались, это любой вид данных которые вовсе не следует какой-либо заранее определенной структуре. Статья, которую вы сейчас читаете, является типичным примером этого. Этот веб-сайт использует Tilda, но база данных работает аналогичным образом - статья сохраняется в виде HTML-кода в поле типа данных, как это было бы в пузыре.Итак, статья сама по себе представляет собой довольно легкий фрагмент данных - это просто текст. По сравнению с изображениями, аудио и видео, это немного, и если бы мы говорили о файле, мы бы не задумывались об этом. Но когда мы говорим о базах данных, мы переходим от единственного числа к множественному. Вопрос не в том, сколько данных содержит одна статья, а в том, как все статьи в списке охватывают. Для иллюстрации рассмотрим еще один пример. На этот раз мы создаем не телефонный каталог, а блог. У нас есть тип данных, называемый статьями, который содержит следующие поля:
- Заголовок: тип данных Text
- Контент: неструктурированный текст
- длинные отрывки текста могут увеличивать время поиска на серверах Bubble
- общий размер каждой записи может расти по мере увеличения количества длинных статей.
Заголовок: 20 байт
Статья: 5 килобайт
Это может показаться небольшим, но давайте еще раз умножим это на тысячу статей, и вы получите общий размер загрузки более 5 мегабайт.
В большинстве случаев, конечно, вы не будете загружать все статьи - вся цель использования ограничений поиска - загрузить только то, что вам нужно, - но это служит иллюстрацией того, что небольшие объемы данных могут быстро увеличиваться при умножении. по количеству записей.
Не все знают, что использование такого плагина, как, Fuzzy Search Zeroqode, фактически загрузит все записи в вашем первоначальном поиске, а затем выполнит поиск на стороне клиента - неосознанно вы можете загружать много данных при загрузке страницы, что значительно увеличит время фильтрации и отклика приложения.
Вес и структурирование данных
Возвращаясь к нашему первоначальному термину «Вес данных» , мы можем сказать, что наш первый пример имеет низкий вес данных, а второй - более высокий, что помогает нам определить, как мы должны эффективно настроить нашу структуру.Сам по себе большой объем данных - неплохая вещь - сохранение неструктурированных данных, конечно, необходимо для самых разных целей, таких как блоги, описания продуктов, новостные статьи и рецепты тортов. Это становится проблемой только тогда, когда она начинает влиять на производительность, и в этом случае мы можем настроить структуру нашей базы данных другим способом.
Один из методов - использование спутниковых типов данных для ускорения поиска и минимизации скорости загрузки.