Basic concepts

IndexedDB는 당신이 유저의 브라우저 안에 데이터를 영구적으로 저장하게 해주는 한 방법이다. 그것은 당신이 network 가능여부에 상관없이 풍부한 query 능력의 web applications를 만들게 해주므로, 이들 application은 online과 offline 모두에서 동작할 수 있다. IndexedDB는 많은 data를 저장하는 applications와 (예를 들어, 대여 도서관 안의 한 DVD catalog) 동작하는데 영구적인 internet 연결이 필요하지 않은 applications에 유용하다(예를 들어, mail clients, to-do lists, 그리고 notepads).

About this document

이 소개글은 IndexedDB 안의 필수 concepts와 용어에 대해 논의한다. 그것은 당신에게 큰 그림을 제공하고 핵심 개념들을 설명한다. IndexedDB 용어들에 대해 더 배우기 위해, Definitions section을 보라. API 사용법에 대한 어떤 자세한 tutorial을 위해, Using IndexedDB을 보라. IndexedDB API에 대한 reference documentation을 위해, IndexedDB article과 그것의 subpages를 보라, 이는 IndexedDB에 사용되는 types of objects를 문서화한다, synchronous 그리고 asynchronous APIs의 methods뿐만 아니라.

Overview of IndexedDB

IndexedDB는 당신이 "key"로 index된 객체를 저장하고 검색하게 해준다. 당신이 database에 만드는 모든 변경은 transactions 안에서 일어난다. 대부분의 web storage solutions와 같이, IndexedDB는 same-origin policy를 따른다. 따라서 당신이 한 domain의 data에 access할 수 있는 동안, 당신은 다른 domains의 data에 접근할 수 없다.

The API는 asynchronous API와 synchronous API 둘 다를 포함한다. The asynchronous API 는 대부분의 경우에 사용될 수 있다, WebWorkers를 포함해서, 반면 the synchronous API는 오직 WebWorkers와만의 사용을 위해 의도되었다. 현재, 어떤 Major browser도 the synchronous API를 지원하지 않는다. 그러나 synchronous APIs가 지원된다 하더라도,당신이 IndexedDB를 사용하는 대부분의 경우에서 , 당신은 보통 asynchronous API를 사용할 것이다.

IndexedDB는WebSQL Database의 대안이다, which the W3C deprecated on November 18, 2010. IndexedDB고와 WebSQL 둘 모두 storage를 위한 solutions이지만, 그들은 같은 functionalities를 제공하지 않는다. WebSQL Database는 relational database access system이고, 반면 IndexedDB는 indexed table system이다.

Big concepts

만약 당신이 다른 type의 데이터베이스와의 작업으로부터의 가정을 가진다면, IndexedDB로 작업할 때 힘들어질 것이다. 그러므로 다음의 중요한 concepts를 염두에 두어라.

IndexedDB databases는 key-value pairs를 저장한다. The values는 complex structured objects가 될 수 있고, keys는 그들objects의 properties가 될 수 있다. Quick searching을 위해 그 objects의 어떤 property를 사용하는 indexes를 만들 수 있다, sorted enumeration뿐만 아니라.
IndexedDB는 transactional database model 위에 만들어진다. 당신이 IndexedDB에서 하는 모든 것은 언제나 transaction의 context 내에서 일어난다. IndexedDB API indexes, tables, cursors, 그 외 다른 것을 나타내는 많은 객체를 제공한다, 그러나 그들 각각은 하나의 특정한 transaction에 묶여있다 . 그러므로, 당신은 transaction의 밖에서 명령을 실행하거나 커서를 열 수 없다.

Transactions는 well-defined lifetime을 가진다, 그러므로 그것이 완료된 후에 transaction을 사용하려 시도하는 것은 예외를 던진다. 또한, transactions은 auto-commit하고 수동으로 commit될 수 없다.

당신이 한 유저가 당신의 웹앱을 두개의 다른 tabs에서 동시에 열면 무엇이 일어날 수 있는지를 고려할 때 이 transaction model은 정말 유용하다. transactional operations이 없이, 그 두 객체들은 모든 서로의 수정에서 충돌할 수 있다. 만약 당신이 database에서의 transactions에 익숙하지 않다면, Wikipedia article on transactions을 읽으라. 또한 Definitions section 아래의 transaction을 보라.
The IndexedDB API는 대부분 asynchronous이다. 그 API는 값을 return하는 것으로 당신에게 data를 주지 않는다; 대신, 당신은 한 callback function을 전달해야 한다. 당신은 하나의 값을 synchronous한 수단을 통해 database에 "저장"하거나 "조회"하지 않는다. 대신, 당신은 한 database operation이 일어나는 것을 "요청"한다. 당신은 그 operation이 완료되었을 때 DOM event를 통해 통지받는다, 그리고 당신이 받은 event의 type은 그 operatoion이 성공했는지 아닌지를 당신이 알게 한다. 이것은 처음에는 조금 복잡하게 들리지만, 만들어진 몇몇 정상동작 측정 방법이 존재한다. 그것은 또한 XMLHttpRequest이 작동하는 방식과 크게 다르지 않다.
IndexedDB는 모든 곳에 requests를 사용한다. Requests는이전에 언급된 성공 또는 실패 DOM events를 받는 객체들이다. 그들은 onsuccess와 onerror properties를 가진다, 그리고 당신은 그들에 대해 addEventListener()와 removeEventListener()를 호출할 수 있다. 그들은 또한 그 request의 상태를 말해주는 readyState, result, 그리고 errorCode properties를 가진다. result property는 특히 magical하다, 왜냐하면 그것은 많은 다른 것이 될 수 있기 때문이다, 그 request가 어떻게 생성되었는지에 따라 (예를 들어, 한 IDBCursor 객체, 또는 당신이 막 데이터베이스에 넣은 한 value에 대한 the key).
IndexedDB는 result가 사용가능하게 되었을 때 당신에게 알리기 위해 DOM events를 사용한다. DOM events는 언제나 type property를 가진다(IndexedDB에서, 그것은 대체로 "success" 또는 "error"로 set된다). DOM events는 또한 그 event가 어디로 향하는지 이야기하는 하나의 target property를 가진다. 대부분의 경우, 한 event의 target은 몇몇 database operation을 행한 결과로서 생성된 IDBRequest object이다. Success events는 bubble up하지 않고 그들은 cancelled될 수 없다. Error events은, 한편으로, bubble하고, cancelled될 수 있다. 이는 매우 중요하다, 왜냐하면 error events은 그들이 달려들어간 어떤 transactions이든 abort하기 때문이다, 그들이 cancelled되지 않는 한.
IndexedDB는 객체 지향이다. IndexedDB은 rows와 columns의 collection인 tables를 가진 한 relational database이 아니다. 이 중요하고 기본적인 차이는 당신이 어플리케이션을 design하고 build하는 방식에 영향을 끼친다.

전통적인 relational data store에서 , 당신은 데이터 행의 collection과 data의 named type의 열을 저장하는 테이블을 가졌을 것이다. IndexedDB은, 한편으로, 당신에게 한 data의 type을 위한 object store를 만들고 단순히 Javascript objects를 그 store에 유지할 것을 요구한다. 각각의 obejct store는 query하고 iterate across하는 것을 효울적으로 만드는 한 collection of indexes를 가질 수 있다. 만약 당신이 object-oriented database management systems에 친숙하지 않다면, Wikipedia article on object database를 읽으라.
IndexedDB는 Structured Query Language (SQL)를 사용하지 않는다. 그것은 당신이 result set을 가로지르며 iterate하기 위해 사용하는 한 cursor를 생성하는 한 index에 대한 queries를 사용한다. 만약 당신이NoSQL systems에 친숙하지 않다면, Wikipedia article on NoSQL를 읽으라.
IndexedDB는 한 same-origin policy에 붙는다. 하나의 origin은 domain, application layer protocol, 그리고 the script가 실행되고 있는 document의 url의 port이다. 각각의 origin은 자신의 연관된 set of databases를 가진다. 모든 database는 하나의 origin 내에서 그를 식별하기 위한 이름을 가진다.

IndexedDB에 도입된 The security boundary 는 어플리케이션이 다른 origin의 data에 accessing하는 것을 막는다. 예를 들어, https://www.example.com/app/ 내의 앱이나 페이지가 https://www.example.com/dir/로부터의 데이터를 조회할 수 있는 데 반해, 왜냐하면 그들이 같은 origin을 가지므로, https://www.example.com:8080/dir/ 또는 https://www.example.com/dir/ (다른 protocol)로부터는 데이터를 조회할 수 없다 (다른 port) , 왜냐하면 그들이 다른 origin을 가지므로.

Definitions

이 section은 IndexedDB API에서 사용되는 용어들을 정의하고 설명한다.

Database

database

정보의 한 repository, 보통 하나 또는 그 이상의 object stores로 구성된다. 각각의 database는 다음을 가져야 한다:

Name. 이것은 하나의 특정 origin 내에서 database를 구별하고 그것의 lifetime 동안 일정하다. The name은 어떤 string값도 될 수 있다 an empty string을 포함해서).
Current version. 하나의 database가 만들어질 때, 따로 기술되지 않으면 its version은 정수 1이다. 어떤 주어진 순간에 각 database는 오직 하나의 version을 가질 수 있다.

object store

Database에 데이터가 저장되는 mechnism. Oobject store는 key-value 쌍인 records를 영구적으로 잡는다. 한 object store 안의 records는 key에 따라 오름차순으로 정렬된다.

모든 object store는 그것의 database에서 유일한 name을 가져야 한다. Object store는 선택적으로 key generator와 key path를 가질 수 있다.만약 object store가 key path를 가진다면, 그것은 in-line keys를 사용한다; 아니면, 그것은 out-of-line keys를 사용한다.

Object store에 대한 참고 문서를 위해, IDBObjectStore 또는 IDBObjectStoreSync를 보라.

version

Database가 처음 만들어질 때, 그것의 version은 interger 1이다. 각 database는 한번에 하나의 version을 가진다; 하나의 데이터베이스가 한번에 여러 version으로 존재할 수 없다. version을 바꾸는 유일한 방법은 현재 버전보다 큰 버전으로 그것을 여는 것이다. 이는 versionchange transaction을 시작하고 upgradeneeded event를 fire한다. database의 schema를 변경할 수 있는 유일한 곳은 그 event의 handler 내부이다.

Note: This definition describes the most recent specification, which is only implemented in up-to-date browsers. Old browsers implemented the now deprecated and removed IDBDatabase.setVersion() method.

database connection

database를 여는 것에 의해 생성되는 operation. 한 주어진 database는 동시에 여러개의 connections를 가질 수 있다.

transaction

특정 database에 대한 data-access와 data-modification operations의 원자적이고 견고한 집합. 그것이 database에서 당신이 data로 상호작용하는 방법이다. 사실, database에서의 어떠한 data의 읽기 또는 변경도 transaction 내에서 일어나야 한다.

하나의 database connection은 한번에 그에 연관된 여러 active transaction을 가질 수 있다, writing transactions이 겹치는 scopes을 갖지 않는 동안. 생성에서 정의되는 transactions의 scope은 그 transaction이 어느 object stores와 상호작용할 수 있는지를 결정하고 그 transaction의 lifetime동안 일정하다. 따라서, 예를 들어, 만약 한 database connection이 flyingMonkey object store를 커버하는 scope의 writing transaction을 이미 가지면, 당신은 unicornCentaur과 unicornPegasus object stores의 scope을 가진 두번째 transaction을 시작할 수 있다. reading transactions로서, 당신은 여러개를 가질 수 있다 — 심지어 겹치는 것들이라도.

Transactions는 short-lived일 것이 기대된다, 그래서 브라우저는 너무 오래걸리는 transaction을 종료할 수 있다, 그 long-running transaction이 lock한 storage resources를 해제하기 위해. 당신은 transaction을 abort할 수 있다 , 이는 그 transaction에서 만들어진 변경들을 roll back한다. 그리고 당신은 심지어 transaction을 abort하기 위해 그것이 시작되거나 활성화되기를 기다릴 필요가 없다.

Transaction의 세가지 모드는: readwrite, readonly, 그리고 versionchange. Object stores와 indexes를 생성하는 유일한 방법은 versionchange transaction을 이용하는 것이다. transaction types를 더 배우기 위해, IndexedDB에 대한 reference article을 보라.

모든 것은 하나의 transaction에서 일어나기 때문에, IndexedDB에서 그것은 매우 중요한 개념이다. transactions에 대해 더 배우기 위해, 특히 그것들이 어떻게 versioning과 관련되는가에 대해, IDBTransaction를 보라, 그는 또한 reference documentation을 가진다. synchronous API에 대한 문서를 위해, IDBTransactionSync를 보라.

request

database에 읽고 쓰기를 행하는 operation. 모든 request는 하나의 읽기 혹은 쓰기 operation을 나타낸다.

index

하나의 index는 다른 object store의 records를 찾기 위한 specialized object store이다, referenced object store라 불리는. index는 그 records의 value part가 referenced object store의 한 record의 key part인 영구적인 key-value storage이다. 하나의 index의 records는 referenced object안에 record가 삽입되고 update되고 삭제될 때마다 자동적으로 생성된다. 하나의 index의 각 record는 그의 referenced object store의 오직 하나의 record를 가리킬 수 있다, 그러나 여러 indexes가 같은 object store를 참조할 수 있다. object store가 변할 때, 그 object store를 참조하는 모든 index는 자동으로 update된다.

다른 방법으로, key를 사용해서 object store에서 records를 찾을 수 있다.

indexes 사용하기에 대해 더 배우기 위해, Using IndexedDB를 보라. index에 대한 reference documentation을 위해, IDBKeyRange를 보라.

Key and value

key

object store에서 이에 의해 저장된 values가 조직되고 조회되는 하나의 data value. object store는 세 sources 중 하나로부터 key를 이끌어낼 수 있다: key generator, key path, 또는 명시적으로 지정된 value. key는 그 앞에 있는 것보다 큰 값을 지닌 한 data type의 것이어야 한다. object store의 각 record는 같은 store 내에서 유일한 key를 가져야 한다, 따라서 당신은 주어진 object store에서 같은 key의 여러 records를 가질 수 없다.

하나의 key는 다음의 types 중 하나가 될 수 있다: string, date, float, 그리고 array. arrays에 대해, key는 empty value로부터 infinity의 범위가 될 수 있다. 그리고 당신은 array 내에 array를 포함할 수 있다. string 또는 integer의 key만 사용해야 한다는 요구사항은 없다.

다른 방법으로, 당신은 index를 사용해서 object store에서 records를 찾을 수 있다.

key generator

정렬 sequence로 새 keys를 생성하기 위한 mechanism. 만약 한 object store가 key generator를 가지지 않으면, application은 저장되는 records를 위한 keys를 제공해야 한다. Generators는 stores 간에 공유되지 않는다. 이것은 브라우저 구현 세부사항에 가깝다, 때문에 web 개발에서, 당신은 실제로 key generators를 만들고 접근할 필요가 없다.

in-line key

저장되는 value의 부분으로서 저장되는 key. key path를 사용함으로써 찾아진다. 하나의 in-line key는 generator를 이용해서 생성될 수 있다. key가 생성된 후에, 그것은 key path를 사용하는 value에 저장될 수 있거나 key로서 사용될 수 있다.

out-of-line key

저장되는 value와는 따로 저장되는 key.

key path

object store 또는 index에서 브라우저가 어디로부터 key를 추출해야 하는지 정의한다. 하나의 valid key path는 다음 중 하나를 포함할 수 있다: an empty string, a JavaScript identifier, or multiple JavaScript identifiers separated by periods. 그것은 spaces를 포함할 수 없다.

value

각각의 record는 하나의 value를 가진다, 이는 javascript로 표현될 수 있는 어떤 것이라도 포함할 수 있다, boolean, number, string, date, object, array, regexp, undefined, 그리고 null을 포함해서.

object 또는 array가 저장될 때, 그 object 또는 array의 properties 와 values는 적합한 어떤 값이라도 될 수 있다.

Blobs와 files가 저장될 수 있다, cf. specification .

Range and scope

scope

한 transaction이 적용되는 object stores와 indexe. read-only transactions의 scope은 겹칠 수 있고 동시에 실행될 수 있다. 한편으로, writing transactions의 scope은 겹칠 수 없다. 당신은 여전히 동시에 같은 scope의 여러 transaction을 실행할 수 있지만 그들은 queue up하고 하나하나 차례로 실행된다.

cursor

한 key range의 여러 records에 대한 iterating을 위한 mechanism. The cursor는 그것이 iterating하는 것이 어느 index또는 object store인지 가리키는 한 source를 가진다. 그것은 그 range 내의 position을 가지고, record keys의 순서에서 증가 혹은 감소하는 한 방향으로 움직인다. cursors에 대한 reference documentation을 위해, IDBCursor 또는 IDBCursorSync를 보라.

key range

keys를 위해 사용되는 몇몇 data type에 대한 하나의 연속 구간. Records는 keys 또는 하나의 range of keys를 사용하는 object sotres와 indexes로부터 조회될 수 있다. 당신은 lower 그리고 upper bound를 사용해서 range를 제한하거나 걸러낼 수 있다. 예를 들어, 당신은 x와 y 사이의 한 key의 모든 값에 대해 iterate할 수 있다.

key range에 대한 reference documentation을 위해, IDBKeyRange를 보라.

Limitations

IndexedDB는 client-side storage가 필요한 대부분의 경우를 cover하기 위해 design되었다 . 하지만 그것은 다음과 같은 몇 가지 경우를 위해서 design되지 않는다:

Internationalized sorting. 모든 언어가 strings를 같은 방법으로 sort하지 않기 때문에 internationalized sorting은 지원되지 않는다. database가 특정 internationalized order로 데이터를 sorting할 수 없는 반면, 당신 스스로 database 바깥으로 data를 읽어와서 sorting할 수 있다.
Synchronizing. The API는 server-side database와의 동기화를 다루기 위해 design되지 않았다. 당신 스스로 client-side indexedDB database를 server-side database와 동기화시키는 코드를 작성해야 한다.
Full text searching. The API는 SQL의 LIKE operator의 equivalent를 가지지 않는다.

덧붙여서, 브라우저가 데이터베이스를 지울 수 있음을 알아두라, 다음과 같은 조건에서:

유저가 삭제를 요청한다. 많은 브라우저는 유저가 주어진 웹페이지에 대해 저장된 데이터를 지울 수 있도록 한다, cookies, bookmarks, stored passwords, 그리고 IndexedDB data를 포함해서.
브라우저가 private browsing mode에 있다. Some browsers, have "private browsing" (Firefox) or "incognito" (Chrome) modes. 그 session의 끝에서, 브라우저는 그 데이터베이스를 지운다.
disk 또는 quota limit에 다다랐다.
데이터가 오염되었다.
그 feature에 호환되지 않는 변경이 이루어졌다.

실제 환경과 브라우저 호환성은 시간에 따라 변하지만, 브라우저 제조사의 기본 철학은 가능한한 데이터를 유지하는 데에 최대한 노력하는 것이다.

Next step

자 이제 이들 지식을 가지고서 , 우리는 더 큰 것들을 가질 수 있게 되었다.the API 사용법에 대한 튜토리얼을 위해서, Using IndexedDB를 보라.