Как лучше всего хранить капли в рельсах 5?

Я создаю приложение для записи звука (rails 5). В настоящее время у меня есть приложение, которое может начать запись, остановить запись и сохранить запись (.wav) в общедоступный каталог. Я создаю BLOB-объект, но в настоящее время я ничего с ним не делаю, так как на самом деле "не знаю, что с ним делать".

Цель этого приложения - записать собственное аудио и сохранить его в своем пользовательском профиле в приложении, а затем выполнить другие различные действия с данными позже. Раньше я использовал carrierwave и paperclip для управления многокомпонентными данными, но я не работал с аудиофайлами, поэтому я не уверен в лучших практиках. Вот некоторые из моих мыслей:

1. Хранение реальных файлов на самом сервере не масштабируется, так что об этом не может быть и речи.
2. Хранение BLOB-объектов в базе данных. Это может сработать, но я не уверен, будет ли заметная неэффективность при конвертации обратно в аудио из BLOB-объектов, а также в потерянные данные.
3. Хранение капель на AWS. В основном те же мысли, что и у # 2, с потерянными данными и неэффективностью при конвертации.
4. Хранение актуальных файлов на AWS. Предполагая, что это возможно. Может быть достаточно большим по размеру ковша, если разрешить длинный звук.

Я действительно склоняюсь к использованию больших двоичных объектов в моей базе данных (# 2), чтобы исключить использование сторонних API, если это хорошая практика. Если это хороший вариант, как бы я сохранил блоб в базе данных? Я вижу bytea как тип данных из нескольких других ответов, но что там будет храниться? Весь блоб?

Пример:

данные: аудио /WAV; base64, GkXfo59ChoEBQveBAULygQRC84EIQoKEd2VibUKHgQRChYECGFOAZwH/////////FUmpZpkq17GDD0JATYCGQ2hyb21lV0GGQ2hyb21lFlSua7 + uvdeBAXPFh16n8rxO9UKDgQKGhkFfT1BVU2Oik09wdXNIZWFkAQEAAIC7AAAAAADhjbWERzuAAJ + BAWJkgSAfQ7Z1Af/////////ngQCjQYiBAACA + 4MC0f/+3/abXFmCecYAQzBpCOhi/o3VWPm9t4OomPezg0lN7vXJNZDU1/lsNMC5P/PIA + 0cQh0Ye5IyXuGV4/IEeblfjEYYqTOlvApzLcAMqI8H1sRhHEHGp8p5KtsBLleXV0qODc7OtgErifrP6CuTzF6qP2AH4i9MlGQwtzxKNLBIHlgOpQgkzw4pByZXK4thmdAXUvRQtAtxYoJcC2/iTY7af0IKBY0siodKsV + VFqAsOndoZJeTI1aG72UB/fo4cZnrUdwmKDROP + J661jhULtSnIKKWsy4jGTE.....

Если это не лучший вариант, дайте мне знать, какой из них будет лучшим и как его достичь?

Изменение: Извините, спойлеры не работают так, как я ожидал.

Изменить 2: некоторые другие вопросы.

Я не уверен, что мне действительно нужно предоставить метод attach после https://edgeguides.rubyonrails.org/active_storage_overview.html. Прямо сейчас я передаю аудио в мой контроллер в виде файла:

#<ActionDispatch::Http::UploadedFile:0x007ff58958a788 @tempfile=#<Tempfile:/var/folders/xb/zm03wqls70gf3thlfy0d67bh0000gn/T/RackMultipart20190414-15311-1essuud.wav>, @original_filename="1555288144507.wav", @content_type="audio/wav", @headers="Content-Disposition: form-data; name=\"audio\"; filename=\"1555288144507.wav\"\r\nContent-Type: audio/wav\r\n">

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

current_user.audio_recordings.attach(
  io: audio, 
  filename: 'file.wav', 
  content_type: 'audio/wav'
)

Кажется, что я мог бы делать гораздо больше тяжелой работы в JS, чем мне, возможно, нужно.

Функция сохранения JS:

function saveRecording() {
    var data = new FormData();

    data.append("audio", recordingBlob, (new Date()).getTime() + ".wav");

    var request = new XMLHttpRequest();
    request.open("POST", "/landing_pages/save_audio");
    request.send(data);
    request.onload = function(oEvent) {
      if (request.status == 200) {
        console.log("Uploaded");
      } else {
        console.log("Error: " + request.status);
      }
    };
  }