С точки зрения мировой энергетики https невыгоден. Ведь для его работы мы обязаны обеспечить обмен ключами и постоянное шифрование трафика. Тоесть TLS/SSL сокет стоит дороже чем простой TCP сокет.
И я думаю что мы последовательно придем к той-же проблеме которая настигла мировой майнинг криптовалют. А именно - электроэнергия для обслуживания майнинга начинает стоить слишком дорого чтобы поддерживать транзакции.
Может быть разница в процентном соотношении между TLS/SSL и raw в мегафлопах не очень велика, но если мы поможим это на статистику https сайтов - то может вылезти такое кругленькое число что как раз можно будет проводить аналогии с криптой и энергетикой Норвегии например.
Станислав, ну давай. Но до того как ты найдешь решение на Go, надо найти принцип.
Будешь ли ты строить дерево на ходу. Или отсортировав как я предложил просто
стримить в json поток.
Владимир Коротенко, проблема - как всегда в людях. Люди - дорого стоят. Найти хорошего девопса чтоб знал Постгре и умел написать баш-скрипты - проблема. Еще проблема - доказать что придуманная только что на коленке технология бэкапа вообще позволит восстановиться. Или восстановиться по состоянию на какую-то точку.
А мы живем в эпоху облаков. Одним мышко-кликом можно поднять хоть оракл хоть mysql. Проблемы ограничений софта уже давно нет. А ограничения людей остались.
На самом деле я - не против хранения музыки на диске. Пускай автор хранит.
Владимир Коротенко, можно по разному на это смотреть. Я-бы смотрел сквозь ценность информации для backup. Вам нужно точно-точно сохранить все? На военном уровне надежности? Или потеря парочки файлов - это нормас. В разных dbms это борют по разному. В Oracle прошла целая эпоха эволюций от raw до специальных опций типа Oracle Securefile которые удешевляют доступ и снимают нагрузку с тела таблиц.
Станислав, это не то что я хотел. Я хотел взять курсор из БД и на уровне SQL решить 50% проблемы. И потом на уровне GoLang + JSON/Serializer/Marshaller решить вторые 50%.
Ты опубликовал то что мне никак не помогает. Я - не специалист в Go. Прошу извинить. Но я собаку съел на базах данных и на экспорте в бигдату и JSON-конверсиях.
Предположительно зависит от качества эфира во время связи по Wifi. У одного из компов - антена или адаптер слабее - и он фиксирует больше ошибок и повторов. Тоесть если ты соединился на скорости 150/300/900Mbit это еще не факт что будешь фактически получать данные так-же.
Вообще, если надо читать то нет никакой разницы по использованию памяти какого размера файл нам нужно открыть, если нет необходимости его весь держать в памяти.
Это из личного опыта. Пользователи и админы любят открывать логи не грепом а текстовым редактором.
Кроме того гранулярность по времени даст вам возможность более точно сужать область поиска.
Ну... можно создать таблицу с авто-инкрементным полем id.
Потом вставить в нее 1 строку.
Потом скопировать таблицу саму в себя.
Тут будет еще двоичный логарим копирований от 100500 ... эээ это где-то ... чуть меньше чем 128Кил... короче 17 раз надо копировать.
Вот. А потом в конце одним update-ом обновить поле hash как хеш-функция от id.
Как хеши делать в MySQL я не помню. Но это справочная инфа.
Со второй таблицей наверное также. Теже самые действия.
Непонятно почему в 21 веке нужно писать кастомные парсеры для CSV.
Это тыщу раз решенная задача. Имеется текстовый файл с разделителями. В данном случае - с пробелами.
Ну а вещественное число с запятой рассматривать уже отдельно как региональные преференции.
Как верно подметил один чел в ответах - надо менять язык.