- From: 이원석 <wslee@etri.re.kr>
- Date: Thu, 9 Dec 2010 08:32:55 +0900
- To: <channy@gmail.com>
- Cc: 박재성 <jaesung.park@nhn.com>, <public-html-ig-ko@w3.org>
- Message-ID: <B4EAD1122C31304099A5CDEA5447210F023A2401@email2>
안녕하세요. 윤석찬 팀장님.
친절한 답변 감사합니다~
아래와 같이 저의 의견을 적어봤습니다~ ;)
From: Channy Yun [mailto:channy@gmail.com]
Sent: Thursday, December 09, 2010 2:53 AM
To: 이원석
Cc: 박재성; public-html-ig-ko@w3.org
Subject: Re: Web SQL Database 관련
더 길어질 필요는 없겠지만 몇 가지만 답변을 드리면요.
è 여러가지 의견을 공유하는 것이 우라 KIG의 중요한 목적중의 하나입니다^^
è 다른 분들도 편하게 의견주세요~ ;)
1. Vlad의 글에서 Web Storage는 http://dev.w3.org/html5/webstorage/ 이구요. 과거 DOM Stroage라고
부르는 sessionStroage와 localStorage입니다. 첫 문장에 링크가 문서에 있습니다. Web Storage나
WebSQLDatabase가 sqlite를 쓰고 있는 아이러니한 현실을 지적한 것입니다.
-à 그러네요^^;; 이건 제가 착각을 하고 있었네요~
à 내용이 주로 SQL 문제와 DB 문제를 이야기 하고 있어서요. 그랬나 봅니다… ;)
2. Web SQL Database가 왜 SQLite를 기반으로 만들어진거죠? SQL문이 SQLite에 종속적인건 이해가 가지만
그 API들은 일반적인 DB 처리 인터페이스와 그리 다르지 않습니다. connect, selectdb, query, fetch, close
이게 다 인데 그냥 rdb 라이브러리지 sqlite 종속적인건 아닙니다.
è 예. API 부분은 문제가 없습니다~ SQL문이 문제가 되는 것이죠.
3. 이런저런 말이 많지만 결론적으로 SQL 구현체를 제공하는 현재 방식 보다 Key/value 기반 저장소를 제공하자는
결론입니다. 그렇게 되면 구현의 정도에 따라 조금의 차이가 있지만 결과적으로 Web Storage와 IndexedDB의
구현물은 결국 같습니다.
è 약간 오해가 있을 것 같아서 다시 한번 말씀드리면,
è 브라우저에서 Web Storage와 IndexedDB의 엔진이 같은지 다른지는 별로 중요한 것이 아니라고 생각됩니다.
è 어떤 API가 제공이 되는지가 중요합니다.
è 예를들어 Web Storage에서 충분한 API가 제공되었다면 DOM Storage Query Language 같이 별도의 솔류션들이 나올 필요가 없을 겁니다.
è 이미 SQLite에 이런 기능이 있지만 Web Storage에서 원하는 API를 제공해 주지 않기 때문에 어떻게 보면 중복이 되는 기능을 js로 또 만들게 되는 것입니다.
4. 실제 현실에서 IndexedDB에다가 수십만행의 데이터를 넣고 처리해야 하는 유즈케이스는 없는데
결국 처음 박재성님의 질문대로 WebSQL Database를 쓸 것이냐 IndexedDB가 나올때 까지 기다리겠냐에서
WebStorage를 써라는 가장 현실적인 답을 한 것입니다.
è 말씀하신데로 IndexedDB가 없는 상황에서 Web Storage를 일단 사용하는 것은 동의합니다~ 다른 대안이 없으니까요.
è 하지만 Web Storage의 구현체가 SQLite이더라도 Web Storage의 간단한 API만을 가지고는 웹앱을 만드는데 한계가 있을 수밖에 없습니다.
우리가 당장 구현을 하는 입장에서 표준의 목적에 따라 쓰고 안쓰고를 고민할 만큼 한가하지 않다고 생각되거든요.
그리고 모바일 웹에서 현재 사용하는 유즈케이스만큼의 데이터를 WebStroage에 넣어 처리했다고 해서 그게 목적을
위배한다고 보여지지도 않습니다.
저도 표준의 목적에 대해서는 이의가 있는 건 아닙니다만 그 범위를 함부로 정하지는 말아야 한다고 생각하네요.
è 이 부분의 의견은 정답이 있는 부분이 아니니 간단하게만 의견을 말씀드리면,
è 제가 활용 범위를 제한한 적은 없는 것 같은데요~ 물론 제가 한정한다고 한정되는 것도 아니구요~ ;)
è 표준을 활용하는 것은 개발자 마음입니다. 하지만 가능하면 목적에 맞게 사용하는 것이 좋을 것이라 생각됩니다^^
이원석 드림.
Channy
---------------------
http://www.linkedin.com/in/channy
* Biomedical Knowledge Engineering Laboratory http://bike.snu.ac.kr
* Daum Developers Network & Affiliates http://dna.daum.net
2010/12/9 이원석 <wslee@etri.re.kr>
안녕하세요. 윤석찬 팀장님.
좋은 의견 감사합니다~
보내주신 의견에 아래와 같이 inline 코멘트를 달았습니다~ ;)
From: Channy Yun [mailto:channy@gmail.com]
Sent: Thursday, December 09, 2010 12:21 AM
To: 이원석
Cc: 박재성; public-html-ig-ko@w3.org
Subject: Re: Web SQL Database 관련
이원석님 말씀은 대부분 맞는 말이지만, 좀 더 깊은 이해가 필요 합니다. (이미 이런 토론은 많았지만요.)
우선 현재 많은 브라우저가 SQLite를 탑재하고 있고, DOM Storage(지금은 Web Storage) 역시 SQLite에
저장되고 있습니다. Key/Value 저장 형식인데도 실제 구현은 브라우저에서 SQLite로 저장하고 있죠.
WebSQL Database는 바로 SQLite에 저장하는 것이구요. 만약 SQLite가 아닌 mySQL로 바꾼다고
생각해 보세요. 브라우저 밑단을 다 바꾸어야 하는 일이 생깁니다. (웹 개발자가 아니라 브라우저 개발자를
말하는 것입니다.)
따라서 IndexedDB로 가는 가장 큰 이유가 바로 Key/Value 형식이 B-tree 기반의 저장소가 낫다고
판단을 하는 것이고 relation이나 대용량 데이터를 다루지 않는 프론트웹의 형식에 가장 적합하고
경우에 따라 MapReduce 기반이나 CouchDB 같은 noSQL을 선택하는 옵션이 가능하다는 점입니다.
(사실 프론트 엔드에 rdb가 있다고 서버의 모든 사용자 데이터를 싱크할 건 아니잖아요 ㅎㅎ)
결론적으로 브라우저는 저장소를 제공하는 것이지 원한다면 웹 개발자가 sql 구현체를 만들어 쓰라는 것입니다.
è 먼저 적어주신 내용을 제가 잘 이해했는지는 모르겠지만 아래와 같이 제 의견을 드릴 수 있을 것 같습니다.
è 아래에 문서로 적어주신 http://blog.vlad1.com/2009/04/06/html5-web-storage-and-sql/ 를 보니 죄송하지만 석찬님께서 조금 잘못 이해를 하고 계시지 않나 생각이 드네요.
è (참고로 이 문서에서 web storage는 DB 기능을 의미하는 것입니다^^ 이게 일반적인 용어라 이런 문제가 있네요^^)
è 위에서 말씀하신 SQLite를 mySQL로 바꾸는 경우의 문제는 DOM Storage 기능과 Web SQL Database 기능이 SQLite를 기반으로 구현이 되어 있기 때문이 아닙니다.
è 왜냐하면 이건 표준의 문제가 아니며, 개발에 대한 이슈입니다. 즉, 플랫폼 개발사의 선택의 문제이기 때문이며, 개발사의 전략에 따라 언제든 좋은 방법으로 다시 구현하면 됩니다.
è 이것 때문에 IndexedDB 표준이 대체표준으로 개발이 되고 있다고 이야기 하는 것은 무리가 있어 보입니다.
è
è 말씀하신 http://blog.vlad1.com/2009/04/06/html5-web-storage-and-sql/ 문서에 보면 Web SQL Database가 왜 상호운용성 문제가 있는지에 대한 이유가 잘 설명이 되어 있습니다.
è SQLite을 사용하면서 발생되는 근본적인 문제는 SQLite의 SQL 변형이라는 것입니다.
è 즉, SQLite에서 사용하는 SQL이 다른 SQL 엔진들과 편차가 크며, 이러한 문제의 가장 큰 원인은 컬럼에 대한 데이터 타입 부분의 편차 때문이라는 것입니다.
è DB의 컬럼에 대한 데이터 타입에 편차가 있다면 당연히 당연히 다른 데이터베이스와는 상호운용성 보장에 문제가 있겠죠.
è 따라서 SQLite를 기반으로 만들어진 기존의 Web SQL Database 스펙이 문제가 된다는 것입니다. 왜냐하면 기존의 DB를 모두 SQLite의 SQL에 맞추어 수정을 해야하니까요.
è 그럼 왜 SQLite가 이러한 문제를 갖을까요? 근본적으로 SQLite의 태생에 있습니다. SQLite는 임베디드 시스템을 위해 개발된 데이터베이스이기 때문입니다.
è 결과적으로 이러한 상호운용성 문제 때문에 SQL을 사용하는 것보다 낮은 레벨의 IndexedDB API 표준을 개발하고 있는 것입니다.
참고.
http://blog.vlad1.com/2009/04/06/html5-web-storage-and-sql/
http://hacks.mozilla.org/category/indexeddb/
어쨌든 SQL 보다 한 단계 낮은 구현체는 브라우저 벤더들의 현실적인 문제에 의한 것이죠. 하지만, 논의만
많이 했지 실제로 구현 속도는 매우 느릴 것으로 예상합니다.
우선 websql db/indexed db를 안(못)쓰고 key/value 저장 형식을 쓰는 게 좋고 그런 측면에서 web storage는
현실적 대안이 됩니다. 원석님께서 web storage가 대량 데이터를 저장하는 것이 적합하지 않다고 하셨는데
구현 측면에서 web sql database와 비교해서 어떤점이 적합하지 않은지 잘 모르겠습니다.
web storage는 cookie를 대체하라고 있는 게 아닙니다. 모바일 웹에서 dom에서 빠르게 핸들링할 수 있는
최소 수준 이상의 데이터를 다루라고 있는 것입니다.
지금은 어차피 db(sqlite)에 담는 것이구요. 예를 들어, websql db를 쓰는 모바일 지메일의 경우 테이블이
top query와 본문내용을 담은 테이블 2개 정도가 주 데이터이고 담아 놓는 메일량도 최신 메일만 보는
서비스적 습성 때문에 20~40개만 인덱싱을 합니다. (그림 참고 http://twitpic.com/3e2uco )
결론적으로 web storage를 가지고 sql 구현체를 만든 아래 js 라이브러리를 보시면 제가 한 말을 이해하실 수
있을 것이라 생각합니다.
http://code.google.com/p/dom-storage-query-language/
è DOM Storage Query Language 같은 좋은 approach를 말씀해 주셔서 감사합니다^^
è 그리고 Web SQL Database와 IndexedDB를 못쓰는 상황에서 Web Storage(여기서는 SessionStorage + LocalStorage를 의미^^)를 사용하고,
è 여기에 DOM Storage Query Language와 같은 Approach로 Web Storage를 DB와 유사하게 활용하는 방식에 대해는 괜찮다고 생각을 합니다.
è 이건 어떤 타겟이 되는 웹앱의 요구사항에 따라서 좋은 솔류션이 될 수 있다고 생각이 듭니다.
è 물론 IndexedDB API를 브라우저들이 제공을 하게되면 어떤 방식이 좋은지 다시 비교가 필요할 것이라고 생각됩니다.
è 그런데 저의 전 메일에 대해서 약간의 오해가 있으신 것 같습니다.
è 제가 지난 메일에서 말씀드리고 싶었던 포인트는 현재 개발되고 있는 Web Storage와 IndexedDB 표준에 대한 각각의 목적입니다.
è 어떤 목적으로 이런 표준들이 개발되고 있는지에 대한 부분입니다.
è 말씀하신데로 Web Storage를 기반으로 DOM Storage Query Language라는 js 프로그램이 나와서 DB 같은 기능을 할 수 있을지는 모르지만
è 이건 Web Storage 표준의 근본적인 목적은 아니라는 것입니다.
è 대량의 데이터를 처리하기 위한 DB 기능을 제공하기 위해 개발 중인 표준은 IndexedDB이며, 따라서 Web Storage + DOM Storage Query Language로 DB 기능을
è 만들 수는 있지만 극히 일부기능이 될 것이며, 성능면에서 IndexedDB를 사용하는 것보다 느릴 것입니다. 또한 Key 값 기준의 순차적인 검색 기능 등 다양한 기능을 js 스크립트로 추가하는 것도 쉽지 않을 것이라 생각이 됩니다.
è 참고로 http://www.w3.org/TR/IndexedDB/ 문서의 소개 부분을 보세요. 아래와 같은 문장이 있습니다.
è User agents need to store large numbers of objects locally in order to satisfy off-line data requirements of Web applications. [WEBSTORAGE <http://www.w3.org/TR/IndexedDB/#bib-WEBSTORAGE> ] is useful for storing pairs of keys and their corresponding values. However, it does not provide in-order retrieval of keys, efficient searching over values, or storage of duplicate values for a key.
è This specification provides a concrete API to perform advanced key-value data management that is at the heart of most sophisticated query processors. It does so by using transactional databases to store keys and their corresponding values (one or more per key), and providing a means of traversing keys in a deterministic order. This is often implemented through the use of persistent B-tree data structures that are considered efficient for insertion and deletion as well as in-order traversal of very large numbers of data records.
이원석 드림
Channy
---------------------
http://www.linkedin.com/in/channy
* Biomedical Knowledge Engineering Laboratory http://bike.snu.ac.kr
* Daum Developers Network & Affiliates http://dna.daum.net
2010/12/8 이원석 <wslee@etri.re.kr>
안녕하세요~ 박재성님.
좋은 질문 감사합니다~
Web SQL Database는 현재 W3C Note Track으로 가는 것에 MS를 비롯해서 모든 기업들이 동의를 하고 있습니다.
그리고 HTML5 에디터인 구글의 Ian Hickson은 WHATWG의 HTML5 문서에서 이에 대한 부분을 이미 제거를 했다고 이야기를 하구요..
개발자 입장에서는 좀 아쉽겠지만 어쩔 수 없는 것 같습니다~
그리고 Web SQL Database가 표준에서 하차를 하게된 이유는 회의때 말씀을 간단하게 드렸었지만,
일단 현재 브라우저들이 모두 SQLite를 내장을 하고 있고 여기서 지원하는 SQL를 표준으로 사용할 수 없기 때문입니다.
또한 SQL이 ISO 표준이 존재하기는 하지만 각 DB만다 다양한 SQL 문을 지원을 하기 때문에 서로 합의할 수 있는 접점을 찾는 것이 힘든 것이 사실입니다.
하지만 이러한 DB 기능은 웹앱에서도 상당히 중요합니다. 그래서 SQL 레벨보다 한단계 낮은 단계의 API를 Indexed Database API라는 표준으로 개발하고 있습니다.
먼저 이러한 기능은 HTML5의 Offline Web Application을 지원하기 위해서는 반드시 필요하죠.
예를 들어 email 웹앱의 경우 통신이 안되는 상황에서도 웹앱을 정상적으로 실행하기 위해서는
웹앱자체의 캐슁도 필요하지만 일부 메일 데이터 자체도 캐슁을 해야합니다.
이럴 때 DB기능은 필수적으로 필요합니다. 이런 경우 Web Storage를 사용하는 것은 적합하지 않습니다.
즉, Web Storage는 간단한 정보를 저장하기 위한 목적이라면, DB기능은 대량의 데이터 관리를 위한 목적입니다.
또한 Web Storage는 키 기반 순차적으로 검색 기능 등 대량의 데이터 관리를 위한 기능을 지원하지 못합니다.
저는 향후 어떻게 될지는 모르겠지만 일단 SQL 레벨보다 한단계 낮은 단계의 Database API를 지원하는 것은 그나마 다행이라고 생각합니다~ ;)
그리고 향후에 이러한 기능 위에 좀더 편리한 기능을 지원하는 추가적인 표준 개발도 가능할 수 있을 것을 봅니다~ ;) 물론 현재까지는 바램이지죠~ ;)
차기 회의때 Web SQL Database와 Indexed Database에 대한 좀더 구체적인 소개를 하는 자리를 갖으면 좋을 것 같습니다.
혹시 발표해주실 분이 계신가요?? Volunteer를 찾습니다~ ;)
이원석 드림.
> -----Original Message-----
> From: public-html-ig-ko-request@w3.org [mailto:public-html-ig-ko-
> request@w3.org] On Behalf Of 박재성
> Sent: Tuesday, December 07, 2010 4:41 PM
> To: public-html-ig-ko@w3.org
> Subject: Web SQL Database 관련
>
> 안녕하세요. NHN의 박재성 입니다.<br><br>KIG 첫 메일을 다른 분들의 의견을
> 구하는 내용으로 시작해 봅니다.<br><br>2차 모임때 이원석 박사님께서 언급해
> 주시기도 했고, 이미 알고 있던 내용이었지만 Web SQL Database가 deprecated 되었다는 내
> 용을 보고<br>조금은 실망(?)스러웠었는데요... (아마도 Indexed DB API가 대체되는
> 형태이겠죠.)<br><br>W3C 내부적으로 논의가 있었겠지만, 이미 Web SQL
> Database는 WebKit 계열의 브라우저에서 구현되어 있고, 몇년동안 계속 <br>사용이 되
> 어왔었는데 굳이 대체할 필요가 있었을까란 생각이 듭니다.<br><br>그리고 아직
> Indexed DB API를 구현한 브라우저도 현재까진 없는 상태이구요.<br>(Firefox 4에
> 서 지원예정이고, 구글코드에 <a
> href="http://code.google.com/p/indexeddb/">http://code.google <http://code.google.com/p/indexeddb/%22%3Ehttp:/code.google>
> .com/p/indexeddb/</a> 구현체가 있긴하지만 오랜시간 동안 구현되어왔던
> <br>Web SQL DB와는 다르다고 생각됩니다.)<br><br>Web SQL
> Database가 deprecated 된 이유 중 하나가 W3C에선 표준화를 위해선 여러 형태의 구현체가 필
> 요한데,<br>현재 Web SQL Database 구현체가 대부분 SQLite로 단일화 되어 있는 형
> 태이기 때문이란 의견도 있더군요.<br><br>HTML5 KIG 다른 분들의 생각은 어
> 떠신지 궁금합니다.<br><br>고맙습니다.<br><br>
> <br><br><br>
Received on Wednesday, 8 December 2010 23:33:36 UTC