자세한 내용이 부족하고 오픈소스 계획도 없는 것 같음에 아쉬움을 느낌, 혹시 ES(ElasticSearch) 대체 방안을 찾다 이 글을 클릭했다면 typesense.org와 duckdb.org(특히 spatial 플러그인 포함)를 추천하고 싶음, 두 서비스 모두 공간 데이터 성능이 우수하고, DuckDB는 변경이 적은 데이터에 대해 실서비스에 쓰기에도 아주 좋아 보임, 클러스터/샤딩 구성에서도 완전한 오픈소스임, 별 연관은 없고 순수한 사용 경험 기반의 추천임
이 두 프로젝트 정말 훌륭함, 우리 팀도 DuckDB를 데이터레이크 검사와 간단한 데이터 가공에 적극적으로 사용 중임, 앞으로 시스템의 다양한 부분을 자세히 설명하는 블로그 글을 추가할 계획임, 한 포스트에 너무 많은 내용을 담으면 읽기 어렵다고 우려해서 내용 분산을 결정함
이런 오픈소스 프로젝트가 있다는 점에 늘 감사함, 하지만 내 프로젝트에 통합하는 건 쉽지 않게 느껴짐, 예전엔 duckdb와 spatial, SQLite 확장들을 정적으로 링크해서 빌드하려다가, 서로 다른 버전의 SQLite 심볼 때문에 빌드가 실패해서 벅차다는 것을 깨달음
DuckDB는 샤딩이나 클러스터링이 전혀 없지 않음? 서버도 따로 없고(HTTP Server Extension 말고는)
Typesense는 성능이 진짜 훌륭하고, 개발 경험도 정말 만족스러움
뭘 오픈소스화할지는 잘 모르겠음, 러스트 코드일까? DB라고 선언하고 있지만 사실 전체 스택을 설명한 느낌임
구직 페이지에서 첫 번째 혜택으로 '오피스 근무 문화'를 강조하는 게 웃기다고 느껴짐, 통근이 어떻게 혜택인지 진심 궁금해짐
통근 vs. 재택은 단순히 이동 시간뿐 아니라 근무 환경, 일과 삶의 균형 등 여러 요소가 있음, 실제로 통근 시간이 30분 이내이고 걷기나 자전거로 이동할 수 있을 때는 매우 즐거웠던 경험임, 운동도 되고 생각 정리도 되고, 집과 일의 전환도 되어줌, 2020년에 풀재택을 할 때는 같은 공간에서 일하고 쉬는 게 점점 힘들어져서, 매일 퇴근 후 한 시간씩 산책하면서 정신적으로 많이 회복했음, 다만 대중교통이나 고속도로로 한 시간 이상 출퇴근했던 적은 힘들었음
오피스 문화가 정말 장점이 있으려면 똑똑한 사람들과 배울 기회, 친구 만들기, 무료 음식/음료, DDR 머신 같은 게 있어야 한다고 생각함, 마지막 오피스 경험에서는 이런 장점이 전혀 없고, 집에서 일하는 것을 대형화한 느낌의 우울한 분위기였음
어떤 사람들은 오피스 출근을 좋아할 수 있음, 사람마다 다름
나는 재택보다 통근을 선호함, 즉, '통근이 혜택'이라고 생각하는 사람 분명 있음
이 시스템이 OSM(OpenStreetMap) 데이터를 위한 오픈소스 ElasticSearch/OpenSearch 엔진 Photon에 도움이 될지 궁금함, 대부분의 OSM 앱에서 검색 경험이 별로고, 오타에도 약한데 Photon은 이 문제에 작은 혁신을 가져옴, Photon 깃허브 링크
이 경우 RocksDB보다 LMDB로 구축된 시스템이 더 잘 맞는다고 생각함, 참고로 OSM Express는 이미 LMDB를 사용하고 있음, OSM Express 위키 링크
메타한 의견이지만, 다시 자체 데이터 저장소나 쿼리 엔진 설계, 블로그 글이 활발해지는 모습이 반가움, 2010년대에 이런 붐이 있었고 최근엔 AI 쪽에 집중 추세였음
그런 붐이 AI 때문이 아니라, 대부분 쓸모가 없다는 게 판명나서였다고 생각함, 기존 시스템을 조정하거나 확장으로 충분히 성능을 맞출 수 있으니 지나치게 특화된 자체 스택은 결국 필요하지 않았음, 제품으로 팔 계획이 없는 사내 전용 스토리지/쿼리 시스템은 결국 리소스 여유 있는 회사의 NIH(Not Invented Here) 신드롬임
NoSQL/대체 데이터베이스가 한때 유행처럼 번지다가, 결국 대부분의 기업에 Postgres 하나만으로 충분하다는 게 알려지면서 사그라짐
아직 더 혁신할 것이 남아 있는지 모르겠음, 실험적인 데이터 저장소보다 믿을 수 있고 검증된 제품을 원함
기사 제목에 "Rust"라는 언어 자체가 포함된 게 이상하다고 느낌, 독자라면 Rust가 뭘 대체하는지—ElasticSearch 인지 MongoDB 인지—헷갈릴 수 있다고 생각함
이 아티클은 너무 세부 정보가 부족함, 예를 들어 데이터 샤딩 방식, 인덱싱과 서비스 간 시간차, 장애 노드 처리, 분산 시스템에서의 지연 시간 등 여러 핵심적인 내용이 빠져 있음
검색 분야에 있는 입장에서, 최근 들어 얼마나 많은 회사들이 "ElasticSearch 대체"를 목표로 하는지 흥미롭게 지켜보고 있음
글 작성자임! 운영 관점에서 "분산 시스템" 문제를 "모놀리식 시스템"으로 전환하는 데 동기부여를 받아, 최근 하드웨어로도 충분히 가능하다는 생각에 RocksDB, Tantivy 같은 임베디드 스토리지 시스템을 택함, 메모리 매핑 덕분에 전 세계를 커버하는 상황도 충족할 수 있었고, 클라우드라 RAM 증설도 자유로움, 데이터 백필과 업데이트는 ES/Mongo와 현재 상태를 따로 신경 쓸 필요 없이, 같은 바이너리로 새 노드에서 전체를 리인덱싱 후 S3로 전송하는 방식으로 간단히 처리함
ElasticSearch 클러스터를 운영하고 관리하는 데 드는 노력과 시간이 실제 운영 데이터베이스보다 훨씬 크게 느껴질 때가 많았음, 이런 점 때문에 여러 상황에선 ES 전체 기능이 아닌 소수 기능만 제공하면서 더 단순하고, 망가질 일 적은 대안을 쓰고 싶다는 생각이 강함
여러 회사가 자신에게 꼭 맞는 솔루션을 조합하는 사례를 보는 게 흥미로움, 특히 처음부터 자체 솔루션을 개발하기보다 상용 오픈소스 툴을 활용해 시작한 점을 긍정적으로 봄, 참고로 Tantivy에서 알게 된 Quickwit이 눈에 들어옴, Lucene 기반의 ES와 비슷한 느낌임, Quickwit 깃허브 링크
tantivy임 :)
Rocks는 Level의 포크이고, Level은 데이터 손상 등 버그로 잘 알려져 있음, 두 시스템 모두 프로덕션에서 많이 쓰였지만, 내가 Level을 썼을 때는 운영팀이 서비스 유지를 위해 에러 처리에 엄청난 고생을 했음, 이런 회사 블로그 포스트는 신기술 스택의 단점이나 심각한 이슈를 절대 솔직히 얘기하지 않음, '빅네임 기업'의 테크 토크도 결국 자기 회사 스토리 광고임
RocksDB는 이미 오래전에 LevelDB와 갈라서, 산업계와 학계에서 대규모 개선이 이루어진 상태임, 이제는 LevelDB와 달리 토이 데이터베이스가 아니라고 생각함, 혹시 발견하지 않은 단점이 있을 수 있지만, RocksDB에서 올 문제 가능성은 희박하다고 봄
내 경험도 다름, 지난 4년간 RocksDB를 수천 대의 서버(서버당 수 테라바이트 데이터)에서 돌렸지만 RocksDB 자체에서 오류가 발생한 적 없음
Elasticsearch라는 키워드 때문에 클릭했는데, radar.com을 몰랐던 게 신기했음, 내가 필요로 하는 적당한 가격대의 오토컴플릿 기능이 보여서 관심이 감
Hacker News 의견
자세한 내용이 부족하고 오픈소스 계획도 없는 것 같음에 아쉬움을 느낌, 혹시 ES(ElasticSearch) 대체 방안을 찾다 이 글을 클릭했다면 typesense.org와 duckdb.org(특히 spatial 플러그인 포함)를 추천하고 싶음, 두 서비스 모두 공간 데이터 성능이 우수하고, DuckDB는 변경이 적은 데이터에 대해 실서비스에 쓰기에도 아주 좋아 보임, 클러스터/샤딩 구성에서도 완전한 오픈소스임, 별 연관은 없고 순수한 사용 경험 기반의 추천임
이 두 프로젝트 정말 훌륭함, 우리 팀도 DuckDB를 데이터레이크 검사와 간단한 데이터 가공에 적극적으로 사용 중임, 앞으로 시스템의 다양한 부분을 자세히 설명하는 블로그 글을 추가할 계획임, 한 포스트에 너무 많은 내용을 담으면 읽기 어렵다고 우려해서 내용 분산을 결정함
이런 오픈소스 프로젝트가 있다는 점에 늘 감사함, 하지만 내 프로젝트에 통합하는 건 쉽지 않게 느껴짐, 예전엔 duckdb와 spatial, SQLite 확장들을 정적으로 링크해서 빌드하려다가, 서로 다른 버전의 SQLite 심볼 때문에 빌드가 실패해서 벅차다는 것을 깨달음
DuckDB는 샤딩이나 클러스터링이 전혀 없지 않음? 서버도 따로 없고(HTTP Server Extension 말고는)
Typesense는 성능이 진짜 훌륭하고, 개발 경험도 정말 만족스러움
뭘 오픈소스화할지는 잘 모르겠음, 러스트 코드일까? DB라고 선언하고 있지만 사실 전체 스택을 설명한 느낌임
구직 페이지에서 첫 번째 혜택으로 '오피스 근무 문화'를 강조하는 게 웃기다고 느껴짐, 통근이 어떻게 혜택인지 진심 궁금해짐
통근 vs. 재택은 단순히 이동 시간뿐 아니라 근무 환경, 일과 삶의 균형 등 여러 요소가 있음, 실제로 통근 시간이 30분 이내이고 걷기나 자전거로 이동할 수 있을 때는 매우 즐거웠던 경험임, 운동도 되고 생각 정리도 되고, 집과 일의 전환도 되어줌, 2020년에 풀재택을 할 때는 같은 공간에서 일하고 쉬는 게 점점 힘들어져서, 매일 퇴근 후 한 시간씩 산책하면서 정신적으로 많이 회복했음, 다만 대중교통이나 고속도로로 한 시간 이상 출퇴근했던 적은 힘들었음
오피스 문화가 정말 장점이 있으려면 똑똑한 사람들과 배울 기회, 친구 만들기, 무료 음식/음료, DDR 머신 같은 게 있어야 한다고 생각함, 마지막 오피스 경험에서는 이런 장점이 전혀 없고, 집에서 일하는 것을 대형화한 느낌의 우울한 분위기였음
어떤 사람들은 오피스 출근을 좋아할 수 있음, 사람마다 다름
나는 재택보다 통근을 선호함, 즉, '통근이 혜택'이라고 생각하는 사람 분명 있음
이 시스템이 OSM(OpenStreetMap) 데이터를 위한 오픈소스 ElasticSearch/OpenSearch 엔진 Photon에 도움이 될지 궁금함, 대부분의 OSM 앱에서 검색 경험이 별로고, 오타에도 약한데 Photon은 이 문제에 작은 혁신을 가져옴, Photon 깃허브 링크
메타한 의견이지만, 다시 자체 데이터 저장소나 쿼리 엔진 설계, 블로그 글이 활발해지는 모습이 반가움, 2010년대에 이런 붐이 있었고 최근엔 AI 쪽에 집중 추세였음
그런 붐이 AI 때문이 아니라, 대부분 쓸모가 없다는 게 판명나서였다고 생각함, 기존 시스템을 조정하거나 확장으로 충분히 성능을 맞출 수 있으니 지나치게 특화된 자체 스택은 결국 필요하지 않았음, 제품으로 팔 계획이 없는 사내 전용 스토리지/쿼리 시스템은 결국 리소스 여유 있는 회사의 NIH(Not Invented Here) 신드롬임
NoSQL/대체 데이터베이스가 한때 유행처럼 번지다가, 결국 대부분의 기업에 Postgres 하나만으로 충분하다는 게 알려지면서 사그라짐
아직 더 혁신할 것이 남아 있는지 모르겠음, 실험적인 데이터 저장소보다 믿을 수 있고 검증된 제품을 원함
기사 제목에 "Rust"라는 언어 자체가 포함된 게 이상하다고 느낌, 독자라면 Rust가 뭘 대체하는지—ElasticSearch 인지 MongoDB 인지—헷갈릴 수 있다고 생각함
이 아티클은 너무 세부 정보가 부족함, 예를 들어 데이터 샤딩 방식, 인덱싱과 서비스 간 시간차, 장애 노드 처리, 분산 시스템에서의 지연 시간 등 여러 핵심적인 내용이 빠져 있음
검색 분야에 있는 입장에서, 최근 들어 얼마나 많은 회사들이 "ElasticSearch 대체"를 목표로 하는지 흥미롭게 지켜보고 있음
글 작성자임! 운영 관점에서 "분산 시스템" 문제를 "모놀리식 시스템"으로 전환하는 데 동기부여를 받아, 최근 하드웨어로도 충분히 가능하다는 생각에 RocksDB, Tantivy 같은 임베디드 스토리지 시스템을 택함, 메모리 매핑 덕분에 전 세계를 커버하는 상황도 충족할 수 있었고, 클라우드라 RAM 증설도 자유로움, 데이터 백필과 업데이트는 ES/Mongo와 현재 상태를 따로 신경 쓸 필요 없이, 같은 바이너리로 새 노드에서 전체를 리인덱싱 후 S3로 전송하는 방식으로 간단히 처리함
ElasticSearch 클러스터를 운영하고 관리하는 데 드는 노력과 시간이 실제 운영 데이터베이스보다 훨씬 크게 느껴질 때가 많았음, 이런 점 때문에 여러 상황에선 ES 전체 기능이 아닌 소수 기능만 제공하면서 더 단순하고, 망가질 일 적은 대안을 쓰고 싶다는 생각이 강함
여러 회사가 자신에게 꼭 맞는 솔루션을 조합하는 사례를 보는 게 흥미로움, 특히 처음부터 자체 솔루션을 개발하기보다 상용 오픈소스 툴을 활용해 시작한 점을 긍정적으로 봄, 참고로 Tantivy에서 알게 된 Quickwit이 눈에 들어옴, Lucene 기반의 ES와 비슷한 느낌임, Quickwit 깃허브 링크
Rocks는 Level의 포크이고, Level은 데이터 손상 등 버그로 잘 알려져 있음, 두 시스템 모두 프로덕션에서 많이 쓰였지만, 내가 Level을 썼을 때는 운영팀이 서비스 유지를 위해 에러 처리에 엄청난 고생을 했음, 이런 회사 블로그 포스트는 신기술 스택의 단점이나 심각한 이슈를 절대 솔직히 얘기하지 않음, '빅네임 기업'의 테크 토크도 결국 자기 회사 스토리 광고임
RocksDB는 이미 오래전에 LevelDB와 갈라서, 산업계와 학계에서 대규모 개선이 이루어진 상태임, 이제는 LevelDB와 달리 토이 데이터베이스가 아니라고 생각함, 혹시 발견하지 않은 단점이 있을 수 있지만, RocksDB에서 올 문제 가능성은 희박하다고 봄
내 경험도 다름, 지난 4년간 RocksDB를 수천 대의 서버(서버당 수 테라바이트 데이터)에서 돌렸지만 RocksDB 자체에서 오류가 발생한 적 없음
Elasticsearch라는 키워드 때문에 클릭했는데, radar.com을 몰랐던 게 신기했음, 내가 필요로 하는 적당한 가격대의 오토컴플릿 기능이 보여서 관심이 감