말씀하신 이종 기기와 데이터 처리에 가장 적합한 데이터 모델이 flexible한 json document가 아닐까 생각됩니다
물론 scale up/down도 무중단으로 자유롭게 조정이 가능하고 scale up으로 한계가 있을 때 scale out을 적용하시는 것이 일반적인 확장 방식입니다
동화기업에서 더 정확한 답변을 드릴 수 있겠지만 MDB의 general solution으로는 data tiering (managed S3 data lake)을 통한 저비용의 스토리지를 활용한 저장과 S3 data 를 직접 query할 수 있는 federated query를 활용하시면 비용 컨트롤이 가능합니다
ㅎㅎ 자체적으로 분석/파악한 내용은 있지만 이 자리에서 말씀드릴 수 있는 내용은 아닌것 같습니다. 한번 연락 주시면 영업대표님을 통해 답변드릴 수 있도록 하겠습니다
큰 의미로 맞는 말씀이지만, MDB는 ACID Tx을 포기했다기 보다는 ACID Tx이 픽수적인 relational data model을 최대한 피해서 Tx의 필요성을 최소화해서 I/O 성능을 높이고 app 개발 생산성을 최대화 시키는 것을 목표로 합니다. ACID Tx을 포기했기 때문에 MDB의 분산시스템이 우수하다기 보다 design에 고려하지 않은 분산 기능을 사후 추가하는 RDB와 달리 distributed by design의 강점을 가지고 있기 때문에 우수한 분산 성능을 보장한다고 보시는 것이 더 맞을것 같습니다. 실제 MDB ACID Tx은 multi-doc, cross-shard까지 지원하고 있습니다
기존에 많이 사용하고 계신 DB는 influxDB로 알고 있습니다. MDB time series collection은 상대적으로 최근에 지원되기 시작했습니다 타 DB대비 이점을 함부로 말씀 드리긴 어렵고 기존 influxDB 고객 중에 국내외에서 MDB time series collection으로 교체하면서 TCO, 성능에 만족스러운 개선을 경험하고 계십니다. 굳이 이점이리면 late-mover advantage라고 생각하시면 좋을것 같습니다. 기존 시계열DB의 단점을 보완한 최신 시계열처리 솔루션이라고 보시면 될것 같습니다
진동 센서의 frequency가 어는 정도 높은 수준인지 모르겠지만 초단위 data injection까지 기본 처리가 가능하고, 더 높은 주기에서 성능에 문제가 우려되신다면 buffering을 통한 bulk write를 통해서 injection 성능을 높여 처리할 수 있습니다
이점이냐 아니냐는 application의 목적에 따라 결정되기 때문에 딱히 이점이다라고 말씀드리긴 어렵지만, 일단, application data model과 storage data model의 일치에서 오는 개발 생산성의 이점, MDB의 경우 relational table에 제한되지 않고 다양한 데이터 모델을 use case에 초적화 시켜서 지원하기 때문에 time series collection, clustered index, graph model 다양한 app의 요구사항을 만족할 수 있고, ACID transaction까지 지원하는 developer data platform이라는 점이 큰 이점입니다. Transaction의 경우 Oracle가 동일한 수준의 snapshot isolation을 지원하고 있습니다
RDB는 design에 수평확장의 개념이 없기 때문에 multi master를 사용한다는 시도자체가 별개의 DB, 독립적인 table이라는 전제가 있어야 할것 같습니다. MDB의 zone sharding의 경우 data localization을 적용할 경우에는 복수의 write node를 적용할 수 있습니다.
글로벌하게 많은 사례가 있습니다. 자동차 생산 공정이나 차량 센서 데이터, 의료 장비의 센서에도 사례가 있습니다
MDB는 아무래도 data platform에 한정되다 보니, 말씀하신 것처럼 end-to-end 에코 시스템에 대해서 명확히 말씀드리긴 어렵지만, 무중단 운영은 SPF를 피하는 방법 외에는 현재로서는 해결책이 없을 것으로 보입니다. device에서 edge, edeg에서 cloud, cloud에서 backend까지 전체적인 시스템은 아무래도 AWS의 IoTCore같은 total solution을 고려해 보시는 것도 좋을 것 같습니다. IoTCore로부터 MDB까지는 stream 방식으로 data injection을 처리할 수 있습니다.
RDBMS도 IoT 시계열 데이터를 지원하는 influxDB, timescaleDB도 있습니다. 이런 DB들은 모두 columnstore, field compression등 시계열 데이터 모델에 적합한 기능을 지원합니다. 이 경우 성능의 문제 보다는 RDB 특성상 RAM/CPU등 resource를 많이 사용한다는 고객들의 complaint이 있습니다. 이에 반해 동일 system resource 기준으로 더 우수한 성능을 실제 보여주고 있어 기존 Relational 시계열DB에서 MDB time series collection으로 교체하는 고객들이 늘어나고 있습니다. 보통 교체하는 고객들은 TCO는 낮아지는 반면 성능은 상승하는 효과를 실제 체험하고 계십니다. MDB의 장점이라면 단지 시계열에 특화된 niche DB가 아니라, time series를 사용하면서도 다른 application에도 적용할 수 있는 general data platform이라는 장점도 고려하시면 좋을것
말씀하신 대로 수평확장을 통한 병렬처리를 통해서 대용량 데이터 처리를 해서 성능을 보장하게 됩니다. RDBMS의 경우 지적하신 제약 외에도 샤딩을 적용하기 위해서는 RDB의 장점인 transaction이나 join을 포기하는 경우도 있습니다. 그에 반해 몽고DB 샤딩은 distributed by design입니다. 대부분 샤딩에서 지원하는 hashed sharding 외에 range sharding, zone sharding까지 지원해서 range query와 data governance도 native support를 하고 있고, chunk rebalancing까지 native support하기 때문에 application 입장에서는 sharding을 사용함에 있어서 크게 차이 없이 개발 생산성을 높일 수 있습니다
MongoDB는 HTAP(OLTP + OLAP)를 지향하는 data platform입니다 Left-Shift 혹은 in-app analytics를 지원해서 ELT업이 데이터 소스를 활용해서 실시간 analytics를 처리하는 것이 best practice이고요 DataLake 가 필요한 경우는 굳이 실시간 처리가 필요하지 않은 시간이 지난 데이터에 대한 analytics에만 선별적으로 적용하실 수 있습니다 Data lake로의 ELT도 별도의 3rd party solution을 추가할 필요 없이 built-in aggregation pipeline으로 처리 가능합니다
안녕하세요