준수의_개발정리노트

이 글은 본인이 공부를 목적으로 공식문서를 읽으며 정리/번역한 글로서 오역이 있을 수 있을 수 있습니다. 또한 본인이 이미 알고 있거나 불필요하다 느끼는 내용들은 누락될 수 있습니다. Models 보통 각각의 model은 데이터베이스 테이블 하나와 매칭된다. 기본: - 모든 model은 python 클래스 django.db.models.Model 의 하위클래스이다. - model의 attribute은 데이터베이스의 field를 나타낸다 아래의 예시는 first_name, last_name이라는 field를 가지는 Person이라는 테이블을 정의한다. from django.db import models class Person ( models . Model ): first_name = models . CharField ( max_length = 30 ) last_name = models . CharField ( max_length = 30 ) 위의 코드는 아래의 SQL과 같다 CREATE TABLE myapp_person ( "id" serial NOT NULL PRIMARY KEY , "first_name" varchar ( 30 ) NOT NULL , "last_name" varchar ( 30 ) NOT NULL ); 알아두면 좋은점: - 보면 python에서는 Person이라고 정의를 하였지만 SQL에서는 myapp_person이라고 생성되는데, 이는 model metadata에 기반하여 자동 생성된 것이며 덮어씌워질 수 있다. - id 필드는 자동으로 생성되며 이 행동 또한 덮어씌워질 수 있다. model 사용하기 model을 변경하거나 추가하면 해당 model이 포함된 app을 INSTALLED_APPS에 추가해야된다. 이러한 경우 꼭 manage.py migrate

원문:  https://www.qwertee.io/blog/postgresql-b-tree-index-explained-part-1/ 원문:  https://en.wikipedia.org/wiki/B-tree Index의 목적은 적은 양의 데이터를 찾을때 disk I/O를 줄이는 것이다. disk를 검색하는 작업은 O(n)이지만 index가 유용하기 위해서는 그보다 더 빨라야한다. PostgreSQL의 default index는 B-Tree로 구성되며 좀 더 정확하게는 B+ Tree로 구성된다. B-Tree와 B+ Tree의 차이점은 key가 저장되는 방식에 있다. B-Tree에서는 각각의 Key들은  leaf node이든 non-leaf node이든 딱 1번만  저장되지만 B+ Tree는 모든 Key들은  leaf node에 존재하고 non-leaf node에도  존재할 수 있다.  Leaf Nodes Leaf Node는 table row을 가리키는 포인터를 가지고 있는  ROWID 와  key 를 가지고 있다. 각각의 leaf node사이에는 index key에 기반한 순서가 있다. 이 순서는 실제로 저장되는 physical order와는 독립적이다. physical order와 독립적이기 때문에 INSERT같은 작업을 하더라도 실제로 data를 옮기지 않고 몇개의 Pointer만을 업데이트하면 되기 때문에 작업을 빠르게 수행할 수 있다. 이렇게 logical order를 따라 저장되어 있기 때문에 오름차순과 내림차순 검색이 가능하다. Internal Nodes(Non-leaf Nodes) 위의 사진을 보면 좀 더 쉽게 이해가 될 것 같은데 internal node에는 pre-define된 범위가 있다. 그리고 포인터들은 각각의 범위안의 노드들을 가리킨다. 즉 위의 예시에서 7보다 작은 key들이 모여져 있는 노드들을 가리키는 포인터, 7~16을 가리키는 포인터 16이상을 가리키는 포인터들이 있다.

Database page: Database에서 page는 DB가 data를 저장/관리하는 가장 기본적인 단위이다. 쉽게 비유하자면,  Database 책 Page Page Row Sentence 하지만  (DB마다 조금씩 다르겠지만), row는 page 용량의 반을 넘어갈 수 없다. https://stackoverflow.com/questions/4401910/mysql-what-is-a-page Clustered Index vs Non-clustered Index: Clustered Index는 index에 저장되는 순서와 같은 순서로 disk에 저장되는 것이다. 따라서 clustered index는 1종류밖에 없다. Non-clustered Index는 실제 물리적으로 저장되는 것과는 별도로 다른 리스트가 존재하는 것이다. 이 리스트는 물리적인 주소값을 저장하고 있는 포인터를 가지고 있다. 만약 모든 column을 반환하고 싶다면 주로 clustered index가 더 빠르다. 이유는 Non-clustered Index는 인덱스에서 테이블을 한번 더 찾아가야 되기 때문이다. https://stackoverflow.com/questions/1251636/what-do-clustered-and-non-clustered-index-actually-mean 어떤 Column에 Index를 생성해야할까? Primary Key를 가지는 새로운 테이블을 생성하게되면 clustered index가 자동으로 primary key의 column에 대해 생성되게 된다. 대부분의 경우에는 괜찮지만 가끔가다 가장 효과적이지 않은 경우도 있다. Clustered Index로 사용되는 column은 unique하고 새로운 entry가 들어갈 때마다 값이 증가되는 column인것이 좋다. 그렇지 않을 경우 새로운 row가 insert될 때마다 index는

https://leopard.in.ua/2015/04/13/postgresql-indexes#.XfeTyugzZaR Index는 추가적인 자료구조로서 아래의 목적들의 달성을 위해 도움이 된다: 1. 데이터 검색 2. Optimizer 3. JOIN 4. Relation: except/intersect를 위해 사용될 수 있다. 5. Aggregation: COUNT/MIN/MAX 등의 Aggregatation function들을 효율적으로 계산할 수 있게 해준다. 6. Grouping Index Types : PostgreSQL에는 여러가지 Index타입들이 있으며 각각 다른 사용법을 가지고 있다. B-Tree index : B-Tree는 CREATE INDEX를 하면 default로 생성되는 index이다. B-Tree의 B는 Balanced의 줄임말로서 트리의 양쪽이 거의 같은 양의 데이터를 가지도록 하는 것이 기본개념이다. B-Tree는 self-balancing 트리로서 sorted data를 유지하고, 검색, 순차적인 접근, 삽입, 삭제를 log시간안에 할 수 있는 자료구조이다. B-Tree는 큰 양의 데이터를 읽고 써야되는 경우에 용이하다. https://en.wikipedia.org/wiki/B-tree R-Tree index : R-Tree는 Rectangle-Tree의 줄임말이다. R-Tree는 주로 공간정보를 저장할 때 사용되는 트리다. 예를 들자면 지리좌표나, 다각형 좌표 등이다. R-Tree의 핵심 아이디어는 가까이 있는 객체들을 그들의  minimum bounding rectangle 로 묶어 한단계 상위 계급인 트리로 표현하는 것이다. 모든 객체들은 이런 bounding rectangle에 포함되어 있고, 이 bounding rectangle과 intersect하지 않는 쿼리는 이 rectangle에 포함된 모든 객체들과도 intersect하지 않는다. leaf 레벨에서는 rectang

If you want to return different types on different queries, you can use **union**. ``` union AgendaItem = StudyGroup | Workout ``` ``` query schedule {   agneda {      ...on  Workout {       name       reps     }      ...on  StudyGroup {       name       subject       students     }   } } ``` ``` ...on  Workout ``` is an inline fragment with the name "Workout" you can also use named fragments (from previous post).

# Why do we need Fragments? Fragments are used to reduce redundancy. You can think of it as something like struct in C. For exmaple, ``` query {   Lift(id: "jazz-cat") {     name     status     capacity     night     elevationGain     trailAccess {       name       difficulty     } }   Trail(id: "river-run"){     name     difficulty     accessedByLifts {       name       status       capacity       night       elevationGain     }   } } ``` you can see that Lift wants   name   status   capacity   night   elevationGain and Trail also wants those fields in "accessedByLifts" In this case, you can use fragment ``` fragment liftInfo on Lift{   name   status   capacity   night   elevationGain } ``` fragment can be used with preceding 3 dots. Following query returns exactly the same result as the upper code: ``` query {   Lift(id: "jazz-cat") {     ...liftInfo     trailAccess {       name       difficulty     } }   Trail(id: "river-run"){     n

Public GraphQL APIs: SWAPI :  http://graphql.org/swapi-graphql GitHub API :  https://developer.github.com/v4/explorer Yelp :  https://www.yelp.com/developer/graphql below examples will be run on :  http://snowtooth.moonhighway.com  < visit the url and type in queries You can add multiple queries to a query document but you can only run  1 query at a time . for example, # Try to write your query here query lifts{ allLifts{ name status } } query trails{ allTrails{ name difficulty } } if you run the query document above, GraphQL playgound will ask you to choose one query to run. To run both queries at once, you need to wrap them into 1 query. query liftsAndTrails { // query : root type. fields that are availabled will be in the documentation. liftCount(status: OPEN) // liftCount : fields chosen from GraphQL documentation allLifts{ // allLifts : fields chosen from GraphQL documentation name status //sele

§ This post is written for personal study purposes §  § This post may include contents from Learning GraphQL : Declarative Data Fetching for Modern Web Apps § What is GraphQL GraphQL is a   query language   for APIs. It is typically served over HTTP. GraphQL queries ask for only the things they need and the server returns those queried rather than returning fields that are programmed. Typically with REST, when the client needs different set of data, you either need to make a new endpoint for that specific need or return a huge sized data that can serve different purposes. However, with GraphQL, client is able to query   only the data that it needs( Underfetching ). Design Principles of GraphQL Hierarchical : Fields are nested and query is shaped like the data it returns. Product Centric : GraphQL is driven by the data needs of the client. Strong Typing : Each data point has specific type and is validated. Client-specific queries Introspective : queries

출처: https://www.elastic.co/guide/en/elasticsearch/reference/current/full-text-queries.html 출처: https://stackoverflow.com/questions/26001002/elasticsearch-difference-between-term-match-phrase-and-query-string 1. term 하나의 term을 찾는다. 이 term은 analyze 되지 않는다. 따라서 대소문자, 복수형 등이 다 구분된다 { "user":"Bennett" } { "query": { "term" : { "user" : "bennett" } } } //아무것도 리턴되지 않는다. (대소문자 구분) 2. match 가장 기본적인 search로 text, number, date, boolean을 사용할 수 있다. text는 검색하기전 analyze된다. fuzzy matching을 지원한다(정확하게 일치하지않더라도 연관성이 있다고 판단하면 리턴). GET /_search { "query": { "match" : { "message" : { "query" : "this is a test" } } } } 3. query_string 입력값을 analyze한다. 사용자가 명시적으로 ""로 둘러싸지않는이상 순서는 상관이 없다. { "foo":"I just said hello world" } { "foo":"Hello world" } { "foo&q

ElasticSearch를 도입하기전, ElasticSearch에대해 공부하기 위해 레퍼런스를 읽으면서 번역&정리한 글입니다. 문서 전체를 번역한 것이 아니라 개인적으로 정리가 필요하다 싶은 내용만 정리하였습니다. 본문:  ElasticSearch 공식레퍼런스 Mapping은 document와 document의 field가 어떻게 저장되고 인덱싱되는지를 정하는 것이다. Field Datatypes: - Simple types like text, keyword, date, long, double, boolean, ip - JSON형식을 띄는 object, nested - 특수한 경우에 사용되는 geo_point, geo_shape, completion 잘모르는 타입들 정리: Keyword datatype: - 주로 이메일주소, 우편번호 등 형식을 갖춘 데이터들을 저장하기 위해 사용된다. - 주로 필터링, 정렬, 종합을 위해 사용된다. - 정확한 값으로면 검색이 가능하다 Text datatype: - text로 지정된 field는 anlayzer를 통해 변환된다.(한글은 anlayzer-nori 플러그인을 별도로 깔아야됨) - 변환된 후에는 ES가 하나의 단어를 전체 내용중에서 찾을 수 있게 해준다. Nested datatype: - nested타입은 object타입의 특수한 형태로써 쉽게 말하자면 object의 list라고 생각하면된다. - 그리고 ES는 inner object라는 형식을 지원하지 않기때문에 이 list를 flatten하여 처리한다. PUT my_index/_doc/1 { "group" : "fans", "user" : [ { "first" : "John", "last" : "Smith" },

ElasticSearch를 도입하기전, ElasticSearch에대해 공부하기 위해 레퍼런스를 읽으면서 번역&정리한 글입니다. 문서 전체를 번역한 것이 아니라 개인적으로 정리가 필요하다 싶은 내용만 정리하였습니다. 본문:  ElasticSearch 공식레퍼런스 PUT /...customer/_doc/1 { "name": "John Doe", "characteristics": "he is tall, fat and wearing blue jacket" } 위의 예시에서 PUT /<index>/<mapping type>/<id> 순이다. 그래서 실제로 쿼리를 보내보면: { "_index" : "...customer", "_type" : "_doc", "_id" : "1", "_version" : 1, "result" : "created", "_shards" : { "total" : 2, "successful" : 1, "failed" : 0 }, "_seq_no" : 0, "_primary_term" : 1 }  이렇게 _type에 _doc이 뜨는 것을 볼 수 있다. mapping type이 7.x버전부터는 없어졌다고 하는데 무엇인지 알아둘겸 읽어보았다. ---여기서부터 원문--- 처음 ElasticSeach(이하 ES)가 출시했을때부터, 각각의 document는 하나의 index와 하나의 mapping type으로 저장되었다. Mapping Type은 document의 타입을