Кажется, что ответ вы не читаете, повторю, minio сравнивали только к minio. В статье нет утверждений типа "minio/ozone производительнее чем..." Для minio были диски SSD два. 4 ядра 16 Гб на узел. 4 узла. Для такого объема датасета вполне.
Мы не сравниваем производительность объектного хранилища A и B в каких-либо единицах. И не хотим, чтобы кто-то делал это на основе нашей статьи. Мы сравниваем поведение хранилища при изменении условий. Т.е. вариант А в момент t1 при условии X1 и в t2 при условии X2, естественно, на одних и тех же машинах. Поэтому акцента на оборудовании нет. Оно адекватное и вполне используемо в производственных малых инсталляциях, оно в целом идентично по ядрам и памяти. Но оборудование вообще не имеет значения, как и не имеют значения абсолютные величины измерения. Но имеет значения только поведение, а именно, деградация производительности на одном и том же железе.
На счет оптимизации при загрузке следует отметить. Включена оптимизация или не включена – маленькие файлы будут.
По поводу «А что мешает выбирать правильную Lakehouse-платформу, в которой есть агрегация мелких файлов в S3» - читайте внимательней, есть ссылки на статьи по исследованию некоторого количества озер данных. Маленькие файлы есть там по множеству причин. Смысл об этом спорить? Это данность эксплуатации больших систем. Ее необходимо просто принять.
По поводу «Ждем теста real-time загрузки данных в GreenPlum!» - так она (загрузка) есть)). Есть Kafka-ADB коннектор, который работает в проде, да и на наших стендах он выдает неплохой перфоманс при загрузке CDC-логов.
Вы правы, S3 — это именно протокол, и напрямую он не ограничивает производительность. В статье речь не о самом протоколе, а о том, как его текущие on-premise реализации (в частности, MinIO) ведут себя в сценариях с большим количеством мелких файлов — и именно в этих реализациях возникают серьёзные узкие места.
При этом даже в облачных сервисах (AWS S3 и др.) при активной работе с мелкими файлами остаются фундаментальные ограничения из-за особенностей API (работа по HTTP, операции с метаданными и т. п.). Поэтому вопрос не только в реализации, но и в архитектурной природе подхода.
Спасибо! Нам кажется, что это все-таки немного разные средства и цели их внедрения различаются, но возможно они могут решать одни и те же задачи. По этой причине не сравнивали.
Кажется, что ответ вы не читаете, повторю, minio сравнивали только к minio. В статье нет утверждений типа "minio/ozone производительнее чем..." Для minio были диски SSD два. 4 ядра 16 Гб на узел. 4 узла. Для такого объема датасета вполне.
Мы не сравниваем производительность объектного хранилища A и B в каких-либо единицах. И не хотим, чтобы кто-то делал это на основе нашей статьи. Мы сравниваем поведение хранилища при изменении условий. Т.е. вариант А в момент t1 при условии X1 и в t2 при условии X2, естественно, на одних и тех же машинах. Поэтому акцента на оборудовании нет. Оно адекватное и вполне используемо в производственных малых инсталляциях, оно в целом идентично по ядрам и памяти. Но оборудование вообще не имеет значения, как и не имеют значения абсолютные величины измерения. Но имеет значения только поведение, а именно, деградация производительности на одном и том же железе.
На счет оптимизации при загрузке следует отметить. Включена оптимизация или не включена – маленькие файлы будут.
По поводу «А что мешает выбирать правильную Lakehouse-платформу, в которой есть агрегация мелких файлов в S3» - читайте внимательней, есть ссылки на статьи по исследованию некоторого количества озер данных. Маленькие файлы есть там по множеству причин. Смысл об этом спорить? Это данность эксплуатации больших систем. Ее необходимо просто принять.
По поводу «Ждем теста real-time загрузки данных в GreenPlum!» - так она (загрузка) есть)). Есть Kafka-ADB коннектор, который работает в проде, да и на наших стендах он выдает неплохой перфоманс при загрузке CDC-логов.
Вы правы, S3 — это именно протокол, и напрямую он не ограничивает производительность. В статье речь не о самом протоколе, а о том, как его текущие on-premise реализации (в частности, MinIO) ведут себя в сценариях с большим количеством мелких файлов — и именно в этих реализациях возникают серьёзные узкие места.
При этом даже в облачных сервисах (AWS S3 и др.) при активной работе с мелкими файлами остаются фундаментальные ограничения из-за особенностей API (работа по HTTP, операции с метаданными и т. п.). Поэтому вопрос не только в реализации, но и в архитектурной природе подхода.
Спасибо! Нам кажется, что это все-таки немного разные средства и цели их внедрения различаются, но возможно они могут решать одни и те же задачи. По этой причине не сравнивали.