데이터베이스에 불이 붙었습니다...

기술적인 이야기를 하나 하겠습니다.

몇 년 전, 저는 협업 기능이 내장된 애플리케이션을 개발하고 있었습니다. 이는 초기 React와 CouchDB의 잠재력을 최대한 활용한 사용자 친화적인 실험 스택이었습니다. JSON을 통해 실시간으로 데이터를 동기화했습니다. OT. 이는 회사 내부적으로 사용되었지만 다른 영역에서의 폭넓은 적용 가능성과 잠재력은 분명했습니다.

이 기술을 잠재 고객에게 판매하려고 시도하는 동안 우리는 예상치 못한 장애물에 직면했습니다. 데모 비디오에서 우리의 기술은 훌륭해 보였고 작동했으며 아무런 문제도 없었습니다. 영상은 그것이 어떻게 작동하는지 정확하게 보여주었고 아무것도 모방하지 않았습니다. 우리는 프로그램을 사용하기 위한 현실적인 시나리오를 생각해내고 코딩했습니다.


사실 이게 문제가 됐다. 우리의 데모는 다른 사람들이 애플리케이션을 시뮬레이션한 방식과 정확히 동일하게 작동했습니다. 특히 대용량 미디어 파일이라 하더라도 정보가 A에서 B로 즉시 전송되었습니다. 로그인한 후 각 사용자는 새로운 항목을 보았습니다. 이 애플리케이션을 사용하면 마을 어딘가에서 인터넷 연결이 중단되더라도 여러 사용자가 동일한 프로젝트에서 명확하게 함께 작업할 수 있습니다. 이는 After Effects의 모든 제품 비디오 컷에 암시적으로 암시되어 있습니다.

모두가 새로 고침 버튼의 용도를 알고 있었지만, 우리에게 빌드하도록 요청한 웹 애플리케이션이 일반적으로 자체적인 제한 사항을 따른다는 사실을 실제로 이해한 사람은 아무도 없었습니다. 그리고 더 이상 필요하지 않다면 사용자 경험은 완전히 달라질 것입니다. 그들은 대화하는 사람들에게 메모를 남겨서 "채팅"할 ​​수 있다는 점을 대부분 알아차렸기 때문에 이것이 예를 들어 Slack과 어떻게 다른지 궁금해했습니다. 휴!

일상적인 동기화 디자인

소프트웨어 개발 경험이 있다면 대부분의 사람들이 인터페이스 그림만 보고 인터페이스와 상호 작용할 때 어떤 작업을 수행할지 이해할 수 없다는 사실을 기억하는 것이 매우 긴장될 것입니다. 프로그램 자체 내부에서 무슨 일이 일어나는지는 말할 것도 없습니다. 지식 수 일어나는 일은 대체로 일어날 수 없는 일과 일어나서는 안되는 일을 아는 결과입니다. 이를 위해서는 정신 모델 소프트웨어가 수행하는 작업뿐만 아니라 개별 부분이 어떻게 조정되고 서로 통신하는지에도 영향을 미칩니다.

이에 대한 전형적인 예는 사용자가 spinner.gif, 작업이 언제 완료될지 궁금합니다. 개발자는 프로세스가 중단되었을 수 있으며 gif가 화면에서 절대 사라지지 않을 것임을 깨달았을 것입니다. 이 애니메이션은 작업 실행을 시뮬레이션하지만 작업 상태와는 관련이 없습니다. 이러한 경우 일부 기술 전문가는 사용자 혼란의 정도에 놀라 눈을 굴리곤 합니다. 그러나 그들 중 얼마나 많은 사람들이 회전하는 시계를 가리키며 그것이 실제로 정지되어 있다고 말하는지 주목하십시오.

이것이 실시간 가치의 본질입니다. 요즘 실시간 데이터베이스는 아직 거의 사용되지 않으며 많은 사람들이 이를 의심스럽게 보고 있습니다. 이러한 데이터베이스의 대부분은 NoSQL 스타일에 크게 의존하고 있기 때문에 일반적으로 가장 잘 잊혀지는 Mongo 기반 솔루션을 사용합니다. 그러나 나에게 이것은 CouchDB로 편안하게 작업하는 것뿐만 아니라 일부 관료만이 데이터로 채울 수 있는 구조를 설계하는 방법을 배우는 것을 의미합니다. 시간을 더 잘 활용하고 있는 것 같아요.

하지만 이 게시물의 실제 주제는 제가 오늘 사용하고 있는 것입니다. 선택에 의한 것이 아니라 무관심하고 맹목적으로 적용된 기업 정책 때문입니다. 따라서 저는 밀접하게 관련된 두 가지 Google 실시간 데이터베이스 제품에 대한 완전히 공정하고 편견 없는 비교를 제공하겠습니다.

둘 다 이름에 Fire라는 단어가 있습니다. 내가 좋아하게 기억하는 한 가지. 두 번째는 다른 유형의 불입니다. 나는 그들의 이름을 말하기를 서두르지 않습니다. 일단 그렇게 하면 우리는 첫 번째 큰 문제인 이름에 직면하게 될 것이기 때문입니다.

첫 번째는 Firebase 실시간 데이터베이스, 그리고 두 번째- Firebase 클라우드 Firestore. 둘 다 회사 제품이에요 Firebase 제품군 Google. 해당 API는 각각 호출됩니다. firebase.database(…) и firebase.firestore(…).

이런 일이 일어난 이유는 실시간 데이터베이스 - 그냥 원본이에요 중포 기지 2014년 Google에서 구매하기 전입니다. 그런 다음 Google은 병렬 제품으로 만들기로 결정했습니다. 복사 빅데이터 회사를 기반으로 하는 Firebase를 클라우드와 함께 Firestore라고 불렀습니다. 아직 혼동하지 않으셨으면 좋겠습니다. 아직도 혼란스럽다면 걱정하지 마세요. 저는 이 부분을 XNUMX번이나 다시 썼습니다.

표시해야 하기 때문에 중포 기지 Firebase 질문에서 소방서 Firebase에 대한 질문에서 적어도 몇 년 전 Stack Overflow에 대한 이해를 돕기 위해.

최악의 소프트웨어 명명 경험에 대한 상이 있다면 이것은 분명히 경쟁자 중 하나일 것입니다. 이러한 이름 사이의 해밍 거리가 너무 작아서 머리가 다른 이름을 생각하는 동안 손가락으로 한 이름을 입력하는 숙련된 엔지니어라도 혼란을 겪습니다. 이것은 비참하게 실패하는 선의의 계획입니다. 그들은 데이터베이스에 불이 붙을 것이라는 예언을 성취했습니다. 그리고 나는 전혀 농담이 아닙니다. 이 명명법을 고안한 사람은 피와 땀과 눈물을 흘렸다.

Pyrrhic victory

Firestore가 교체 Firebase는 차세대 제품이지만 이는 오해의 소지가 있습니다. Firestore는 Firebase를 적절하게 대체할 수 있다고 보장되지 않습니다. 누군가가 흥미로운 모든 것을 잘라내고 나머지 대부분을 다양한 방식으로 혼동한 것 같습니다.

그러나 두 제품을 잠깐 살펴보면 혼란스러울 수 있습니다. 기본적으로 동일한 API를 통해, 심지어 동일한 데이터베이스 세션에서도 동일한 작업을 수행하는 것처럼 보입니다. 차이점은 미묘하며 광범위한 문서에 대한 신중한 비교 연구를 통해서만 드러납니다. 또는 Firestore에서 작동하도록 Firebase에서 완벽하게 작동하는 코드를 포팅하려는 경우입니다. 그럼에도 불구하고 실시간으로 마우스를 드래그 앤 드롭하려고 하면 데이터베이스 인터페이스가 켜진다는 것을 알게 됩니다. 반복합니다. 농담이 아닙니다.

Firebase 클라이언트는 변경 사항을 버퍼링하고 마지막 쓰기 작업에 우선순위를 부여하는 업데이트를 자동으로 재시도한다는 점에서 정중합니다. 그러나 Firestore에는 문서당 사용자당 초당 1회의 쓰기 작업 제한이 있으며 이 제한은 서버에 의해 적용됩니다. 이를 사용하여 작업할 때 애플리케이션을 구축하려고 할 때에도 이를 해결하는 방법을 찾고 업데이트 속도 제한기를 구현하는 것은 사용자에게 달려 있습니다. 즉, Firestore는 API를 사용하는 것처럼 가장하는 실시간 클라이언트가 없는 실시간 데이터베이스입니다.

여기서 우리는 Firestore의 존재 이유에 대한 첫 번째 징후를 보기 시작합니다. 내 생각이 틀렸을 수도 있지만, Google 경영진의 누군가가 Firebase를 구매한 후 보고 단순히 "아니요, 맙소사, 아니죠. "라고 말한 것 같습니다. 이것은 용납될 수 없습니다. 내 지도하에 있지 않을 뿐이야."

그는 자신의 방에서 나타나 다음과 같이 선언했습니다.

“큰 JSON 문서 하나요? 아니요. 데이터를 각각의 크기가 1MB 이하인 별도의 문서로 분할하게 됩니다.”

그러한 제한은 충분히 동기가 부여된 사용자 기반과의 첫 만남에서 살아남지 못할 것 같습니다. 당신은 그것이라는 것을 알고 있습니다. 예를 들어, 직장에서는 XNUMX만 개 이상의 프레젠테이션이 있는데 이는 완전히 정상적인 수준입니다.

이러한 제한으로 인해 데이터베이스에 있는 하나의 "문서"는 사용자가 문서라고 부르는 개체와 유사하지 않다는 사실을 받아들여야 합니다.

"다른 요소를 재귀적으로 포함할 수 있는 배열의 배열? 아니요. 배열에는 신이 의도한 대로 고정 길이의 객체나 숫자만 포함될 것입니다."

따라서 GeoJSON을 Firestore에 넣으려는 경우 이것이 불가능하다는 것을 알게 될 것입니다. 64차원적이지 않은 것은 허용되지 않습니다. JSON 내의 BaseXNUMX 및/또는 JSON이 마음에 드셨으면 좋겠습니다.

“HTTP, 명령줄 도구 또는 관리 패널을 통해 JSON 가져오기 및 내보내기? 아니요. Google Cloud Storage로만 데이터를 내보내고 가져올 수 있습니다. 지금은 그렇게 부르는 것 같아요. 그리고 제가 "당신"이라고 말할 때는 프로젝트 소유자 자격을 갖춘 사람들에게만 말하는 것입니다. 다른 사람들도 가서 티켓을 만들 수 있어요."

보시다시피 FireBase 데이터 모델은 설명하기 쉽습니다. 여기에는 JSON 키를 URL 경로와 연결하는 하나의 거대한 JSON 문서가 포함되어 있습니다. 으로 쓴다면 HTTP PUT в / FireBase는 다음과 같습니다.

{
  "hello": "world"
}

그 GET /hello 돌아올 것이다 "world". 기본적으로 예상한 대로 정확하게 작동합니다. FireBase 객체 컬렉션 /my-collection/:id JSON 사전과 동일 {"my-collection": {...}} 루트에서 그 내용을 사용할 수 있습니다. /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

이는 각 삽입물에 충돌 없는 ID가 있고 시스템에 표준 솔루션이 있는 경우 제대로 작동합니다.

즉, 데이터베이스는 100% JSON(*)과 호환되며 CouchDB와 같은 HTTP와 잘 작동합니다. 그러나 기본적으로 웹소켓, 인증 및 구독을 추상화하는 실시간 API를 통해 이를 사용합니다. 관리자 패널에는 실시간 편집과 JSON 가져오기/내보내기가 모두 가능한 두 가지 기능이 모두 있습니다. 코드에서 동일한 작업을 수행하는 경우 패치 및 차이점 JSON이 지속 상태를 처리하는 일상적인 작업의 90%를 해결한다는 사실을 알게 되면 얼마나 많은 특수 코드가 낭비되는지 놀라게 될 것입니다.

Firestore 데이터 모델은 JSON과 유사하지만 몇 가지 중요한 측면에서 다릅니다. 나는 이미 배열 내에 배열이 부족하다고 언급했습니다. 하위 컬렉션 모델은 해당 컬렉션이 포함된 JSON 문서와 별개로 최고 수준의 개념이 되도록 하는 것입니다. 이에 대해 미리 만들어진 직렬화가 없기 때문에 데이터를 검색하고 쓰려면 특수한 코드 경로가 필요합니다. 자신의 컬렉션을 처리하려면 자신만의 스크립트와 도구를 작성해야 합니다. 관리 패널에서는 한 번에 한 필드씩만 변경할 수 있으며 가져오기/내보내기 기능은 없습니다.

그들은 실시간 NoSQL 데이터베이스를 가져와 자동 조인과 별도의 비JSON 열을 갖춘 느린 비SQL로 전환했습니다. GraftQL과 같은 것.

핫 자바

Firestore가 더 안정적이고 확장 가능해야 한다면 아이러니한 점은 일반 개발자가 기본적으로 FireBase를 선택하는 것보다 덜 안정적인 솔루션을 사용하게 된다는 것입니다. Grumpy Database Administrator가 필요로 하는 종류의 소프트웨어에는 제품이 잘해야 하는 틈새 시장에 비해 비현실적인 수준의 노력과 재능이 필요합니다. 이는 개발 도구와 플레이어가 없으면 HTML5 Canvas가 Flash를 전혀 대체할 수 없는 것과 유사합니다. 더욱이 Firestore는 일반 비즈니스 사용자의 방식과 일치하지 않는 데이터 순수성과 무균 검증에 대한 요구에 빠져 있습니다. 일하는 것을 좋아한다: 그에게는 모든 것이 선택 사항입니다. 왜냐하면 끝까지 모든 것이 초안이기 때문입니다.

FireBase의 가장 큰 단점은 대부분의 웹 개발자가 불변성에 대해 알기 전에 클라이언트가 시대보다 몇 년 앞서 만들어졌다는 것입니다. 이 때문에 FireBase는 사용자가 데이터를 변경할 것이라고 가정하므로 사용자가 제공한 불변성을 활용하지 않습니다. 또한 사용자에게 전달하는 스냅샷의 데이터를 재사용하지 않으므로 비교가 훨씬 더 어려워집니다. 대규모 문서의 경우 변경 가능한 diff 기반 트랜잭션 메커니즘이 부적절합니다. 여러분, 우리는 이미 WeakMap 자바스크립트에서. 편안해요.

데이터에 원하는 모양을 제공하고 나무를 너무 크게 만들지 않으면 이 문제를 피할 수 있습니다. 하지만 개발자가 데이터베이스 설계에 대한 진지하고 실용적인 조언과 함께 불변성을 사용하는 정말 훌륭한 클라이언트 API를 출시한다면 FireBase가 훨씬 더 흥미로울지 궁금합니다. 대신 그들은 깨지지 않은 것을 고치려고 노력하는 것 같았고, 그것이 상황을 더욱 악화시켰습니다.

Firestore 생성의 모든 논리를 알지 못합니다. 블랙박스 내부에서 어떤 동기가 생길지 추측해 보는 것도 재미다. 매우 유사하지만 비교할 수 없는 두 데이터베이스를 병치하는 경우는 매우 드뭅니다. 누군가가 생각한 것과 같습니다. "Firebase는 Google Cloud에서 에뮬레이션할 수 있는 기능일 뿐입니다.", 그러나 실제 요구 사항을 식별하거나 이러한 요구 사항을 모두 충족하는 유용한 솔루션을 만드는 개념을 아직 발견하지 못했습니다. “개발자들이 그것에 대해 생각하게 해주세요. UI만 아름답게 만들어주세요... 불을 더 추가해주실 수 있나요?”

나는 데이터 구조에 대해 몇 가지를 이해합니다. 나는 확실히 "하나의 큰 JSON 트리에 있는 모든 것" 개념을 데이터베이스에서 대규모 구조의 감각을 추상화하려는 시도로 봅니다. 소프트웨어가 모호한 데이터 구조 프랙탈에 간단히 대처할 것이라고 기대하는 것은 미친 짓입니다. 상황이 얼마나 나쁠지 상상할 필요도 없습니다. 엄격한 코드 감사를 수행했고 나는 너희들이 꿈도 꾸지 못한 것들을 보았다.. 하지만 나는 또한 좋은 구조가 어떤 것인지 알고 있습니다. 그것들을 사용하는 방법 и 왜 이런 일이 이루어져야 하는가?. Firestore가 논리적으로 보이고 Firestore를 만든 사람들이 자신들이 훌륭한 일을 했다고 생각하는 세상을 상상할 수 있습니다. 그러나 우리는 이 세상에 살고 있지 않습니다.

FireBase의 쿼리 지원은 어떤 표준에서도 열악하며 사실상 존재하지 않습니다. 확실히 개선이 필요하거나 최소한 수정이 필요합니다. 그러나 Firestore는 일반 SQL에서 발견되는 것과 동일한 XNUMX차원 인덱스로 제한되기 때문에 그다지 나아지지 않습니다. 사람들이 혼란스러운 데이터에 대해 실행하는 쿼리가 필요한 경우 전체 텍스트 검색, 다중 범위 필터 및 사용자 정의 사용자 정의 순서가 필요합니다. 자세히 살펴보면 일반 SQL의 기능은 그 자체로 너무 제한적입니다. 또한 사람들이 프로덕션에서 실행할 수 있는 유일한 SQL 쿼리는 빠른 쿼리입니다. 스마트 데이터 구조를 갖춘 맞춤형 인덱싱 솔루션이 필요합니다. 다른 모든 것에는 최소한 증분 맵 축소나 이와 유사한 것이 있어야 합니다.

이에 대한 정보를 Google Docs에서 검색하면 BigTable 및 BigQuery와 같은 방향으로 나아갈 수 있기를 바랍니다. 그러나 이러한 모든 솔루션에는 너무 많은 기업 영업 전문 용어가 수반되어 있으므로 빨리 되돌아가서 다른 것을 찾기 시작할 것입니다.

실시간 데이터베이스에서 가장 원하지 않는 것은 관리급 급여를 받는 사람들이 만들고 그들을 위해 만든 것입니다.

(*) 농담이고 별거 없습니다 100% JSON 호환.

광고의 권리에

찾고있는 VDS 프로젝트 디버깅을 위한 서버, 개발 및 호스팅을 위한 서버? 당신은 확실히 우리의 고객입니다 🙂 다양한 구성의 서버, DDoS 방지 및 Windows 라이센스에 대한 일일 가격이 이미 가격에 포함되어 있습니다.

출처 : habr.com