음...그러니까 형식적인 차이에서 오는 이점 말고는 정해진 장점 같은건 없는거? - dc App
익명(175.201)2021-10-13 23:36
비정규화 돼있어서 조인으로 데이터를 안긁어오니까 바로바로 셀렉해서 빠른거로 알고 있음.
사서조무사(syachiku)2021-10-13 23:25
답글
아 그럼 단지 join을 사용하느냐 않느냐의 차이인가? - dc App
익명(175.201)2021-10-13 23:36
역정규화는 알디비도 할수는 있는데 기본적으로 데이터 사이즈가 존나 커져서 몇백대 이상 나눠서 처리해야 할때 효율적으로 처리할 방법을 고민해서 나온 놈들임 기존 알디비엠에스들은 기본적으로 한 박스에서 효율적으로 처리할 방법을 고민했는데 거기서 확장할 방법을 찾다 다 때려치고 근본적으로 새로 고민한거 - dc App
sloth(218.147)2021-10-13 23:29
답글
박스 하나에 올라갈 데이터면 아무 알디비나 써도 무방해 - dc App
sloth(218.147)2021-10-13 23:31
답글
그러니까 알디비를 정규화 안하고 인덱스ㅡ컬럼하나만 해두고 샤딩해서 관리하면 기본적인 nosql이라고 생각하면 되는건가??
나와있는 nosql 서비스들은 여기서 어떤걸 더 쓰기 편하고 효율 좋게 만든거고? - dc App
익명(175.201)2021-10-13 23:35
답글
"기본적인 nosql"이라는게 없다니깐.. nosql 대표주자 몽고랑 카산드라 보면 근본적으로 다르고 공통점이라곤 rdbms가 아니라는 것 밖에 없음
nvm(milizz)2021-10-13 23:38
답글
밑에 형이 말한것처럼 nosql은 알디비를 제외한 놈들이라 여러가진데 일단 알디비는 릴레이션을 데이터 모델로 하고 acid 특성을 만족시키는 트랜잭션 구현을 효율적으로 하고 한 박스에서 디스크io를 줄이고 인덱스 같은걸 효율적으로 구현하는걸 고민해왔다면은 - dc App
sloth(218.147)2021-10-13 23:42
답글
nosql은 아예 거기에서 벗어나서 수백대 분산 시스템에서 노드간의 효율적인 자원이나 작업분배등을 고민하고 데이터 모델도 릴레이션에서 벗어나고 트랜잭션도 그에 맞게 느슨한 cap이나 base 이론을 따르자하고 암튼 목적과 고민이 달라 그래서 적절한 응용분야도다르고 - dc App
sloth(218.147)2021-10-13 23:45
답글
그럼 분산시스템에서 더 효율적으로 사용할 방법을 고민한 시스템이기 때문에 그 특성에 맞게 사용하면 복잡한 구현없이 편하게 좋은 성능을 낼 수 있다. 정도로 이해하면 될까? - dc App
익명(175.201)2021-10-13 23:49
답글
근데 데이터 모델이 릴레이션이어야 한다거나 rdbms에서 제공하는 무결성등이 중요하다거나 하면 훨씬 쓰기 어려운 놈이 되기가 쉬워 예를 들어 게시판같은 순차적으로 증가하는 키쓰고 최근글 기준으로 페이지네이션하고 글쓴 아이디로 조인해서 다른거 처리하고 하거나 복잡한 결제로직 같은것들은 hbase같은 놈보다 알디비가 훨씬 적절하고 - dc App
sloth(218.147)2021-10-13 23:59
답글
음... 그러면 성능이란거 자체를 보면 안되고 성능을 위해서 어떤 데이터베이스를 선택해야 하는가가 중요하다는건가? - dc App
익명(175.201)2021-10-14 00:00
답글
데이터 모델과 해당 nosql이 트랜잭션을 어떻게 처리하는지 보고 그게 형 응용에서 받아들일수 있는지 본 후에 트래픽 볼륨을 고민해보고 알디비써서 리플리케이션이나 샤딩으로 처리가 힘들겠다고 견적이 나오면 고민해봐 아니면 응용프로그램 만들기가 엄청 힘들거야 모델링도힘들고 - dc App
sloth(218.147)2021-10-14 00:07
답글
사족을 붙이면은 제프딘이 새로 만들면 다르게 만들었을거라고 인터뷰했던게 빅테이블로 기억해 트래픽 사이즈는 기존 알디비로 감당이 안되서 만들기는 했는데 응용 만드는 애들이 힘들어한경우가 많았다고 그래서 그 다음에 나온게 메가스토어 스패너 이런애들이고 - dc App
sloth(218.147)2021-10-14 00:10
답글
감사.. 다른게 아니라 하둡이랑 이쪽으로 좀 공부하는 중인데 검색만으로는 이해가 안되는게 너무 많아서 진짜 많이 배웠어... - dc App
익명(175.201)2021-10-14 00:13
NoSQL은 그냥 RDBMS 아닌거 묶어놓은거라 데이터 많은 상황에서 왜 더 나은지에 대한 답변이 해당 NoSQL에 따라 다름
https://softwareengineering.stackexchange.com/a/175546
음...그러니까 형식적인 차이에서 오는 이점 말고는 정해진 장점 같은건 없는거? - dc App
비정규화 돼있어서 조인으로 데이터를 안긁어오니까 바로바로 셀렉해서 빠른거로 알고 있음.
아 그럼 단지 join을 사용하느냐 않느냐의 차이인가? - dc App
역정규화는 알디비도 할수는 있는데 기본적으로 데이터 사이즈가 존나 커져서 몇백대 이상 나눠서 처리해야 할때 효율적으로 처리할 방법을 고민해서 나온 놈들임 기존 알디비엠에스들은 기본적으로 한 박스에서 효율적으로 처리할 방법을 고민했는데 거기서 확장할 방법을 찾다 다 때려치고 근본적으로 새로 고민한거 - dc App
박스 하나에 올라갈 데이터면 아무 알디비나 써도 무방해 - dc App
그러니까 알디비를 정규화 안하고 인덱스ㅡ컬럼하나만 해두고 샤딩해서 관리하면 기본적인 nosql이라고 생각하면 되는건가?? 나와있는 nosql 서비스들은 여기서 어떤걸 더 쓰기 편하고 효율 좋게 만든거고? - dc App
"기본적인 nosql"이라는게 없다니깐.. nosql 대표주자 몽고랑 카산드라 보면 근본적으로 다르고 공통점이라곤 rdbms가 아니라는 것 밖에 없음
밑에 형이 말한것처럼 nosql은 알디비를 제외한 놈들이라 여러가진데 일단 알디비는 릴레이션을 데이터 모델로 하고 acid 특성을 만족시키는 트랜잭션 구현을 효율적으로 하고 한 박스에서 디스크io를 줄이고 인덱스 같은걸 효율적으로 구현하는걸 고민해왔다면은 - dc App
nosql은 아예 거기에서 벗어나서 수백대 분산 시스템에서 노드간의 효율적인 자원이나 작업분배등을 고민하고 데이터 모델도 릴레이션에서 벗어나고 트랜잭션도 그에 맞게 느슨한 cap이나 base 이론을 따르자하고 암튼 목적과 고민이 달라 그래서 적절한 응용분야도다르고 - dc App
그럼 분산시스템에서 더 효율적으로 사용할 방법을 고민한 시스템이기 때문에 그 특성에 맞게 사용하면 복잡한 구현없이 편하게 좋은 성능을 낼 수 있다. 정도로 이해하면 될까? - dc App
근데 데이터 모델이 릴레이션이어야 한다거나 rdbms에서 제공하는 무결성등이 중요하다거나 하면 훨씬 쓰기 어려운 놈이 되기가 쉬워 예를 들어 게시판같은 순차적으로 증가하는 키쓰고 최근글 기준으로 페이지네이션하고 글쓴 아이디로 조인해서 다른거 처리하고 하거나 복잡한 결제로직 같은것들은 hbase같은 놈보다 알디비가 훨씬 적절하고 - dc App
음... 그러면 성능이란거 자체를 보면 안되고 성능을 위해서 어떤 데이터베이스를 선택해야 하는가가 중요하다는건가? - dc App
데이터 모델과 해당 nosql이 트랜잭션을 어떻게 처리하는지 보고 그게 형 응용에서 받아들일수 있는지 본 후에 트래픽 볼륨을 고민해보고 알디비써서 리플리케이션이나 샤딩으로 처리가 힘들겠다고 견적이 나오면 고민해봐 아니면 응용프로그램 만들기가 엄청 힘들거야 모델링도힘들고 - dc App
사족을 붙이면은 제프딘이 새로 만들면 다르게 만들었을거라고 인터뷰했던게 빅테이블로 기억해 트래픽 사이즈는 기존 알디비로 감당이 안되서 만들기는 했는데 응용 만드는 애들이 힘들어한경우가 많았다고 그래서 그 다음에 나온게 메가스토어 스패너 이런애들이고 - dc App
감사.. 다른게 아니라 하둡이랑 이쪽으로 좀 공부하는 중인데 검색만으로는 이해가 안되는게 너무 많아서 진짜 많이 배웠어... - dc App
NoSQL은 그냥 RDBMS 아닌거 묶어놓은거라 데이터 많은 상황에서 왜 더 나은지에 대한 답변이 해당 NoSQL에 따라 다름
아아아 그러니가 정확하게는 알디비가 아닌것들이 nosql일 뿐이고 형식적인 차이밖에는 없다는거지?? - dc App
형식적인 차이가 아니라 목적이 달라서 고민하거나 최적화한 방향도 다르고 적합한 응용도 달라 아마 내 댓글이나 nvm형의 댓글을 잘못이해한듯 - dc App