USB로 우분투를 설치하는 경우, 부트로더에서 USB로 부팅을 하면 커서만 깜빡이고 진행이 멈춰버리는 증상이 나타날 때가 있다.
다시 재부팅해서 USB로 부팅하면 설치가 잘 된다.
ssh localhost를 하였을때, Read from socket failed: Connection reset by peer 라는 메시지가 튀어 나오면서 접속이 안되는 경우가 있다.
이경우 ssh_config파일을 죽어라 재설정 해도 잘 되지 않는다.
일단, 이 메시지가 나오면 포트를 확인해본다.
$ lsof -i:22
현재 LISTEN 상태인지 다른 프로세스하고 ESTABILISHED 되어 있는지 확인한다. 상태가 LISTEN이 아니거나 아무것도 안나오면 서버가 실행되지 않은것이고 다른 프로세스하고 ESTABILISHED되어있으면 해당 프로세스를 과감히 kill 해준다.
하지만
sshd 2750 root 3r IPv4 15134 0t0 TCP *:ssh (LISTEN)
sshd 2750 root 4u IPv6 15136 0t0 TCP *:ssh (LISTEN)이런식으로 나올경우 서버 자체는 정상 작동하고 다른 프로세스하고는 연관이 없다. 그냥 재설치 하자.
재설치를 그냥 reinstall 옵션을 사용해도 좋지만 서버의 경우 설정파일이 그냥 남아 있는 경우가 있으므로, 제일 먼저 설정파일을 관리자 권한으로 모조리 삭제 해준다.
$ sudo rm /etc/ssh/sshd_config
그 다음은 purge 옵션으로 서버를 삭제 해주고 재설치를 하면 된다.
$ sudo apt-get purge openssh-server
$ sudo apt-get install openssh-server
이제 마지막으로 재부팅을 한후에 다시 실행하면 잘 접속 될 것이다.
메모리가 부족할 경우 시스템이 멈추거나 장애가 생긴다.
Ubuntu의 경우 Bus error이라는 메시지가 나오는 경우 보통 메모리 문제인데
이경우 Swap 메모리를 늘려주면 해결된다.
1. Swap 메모리를 늘리기 위해서는 root유저로 로그인 해야한다.
$ su - OR $ sudo -s
2. Swap메모리로 사용될 가상 파일을 생성해준다.
$ dd if=/dev/zero of=/swapfile bs=1024 count=3145728
#(**여기서 3145728는 1024*1024*3으로 나온것이며 3GB를 나타낸다**)
그러면 약 2~3분후 다음과 같이 결과가 나온다.
3145728+0 records in
3145728+0 records out
3221225472 bytes (3.2 GB) copied, 504.698 s, 6.4 MB/s3. 만들어진 Swap 파일을 리눅스에서 사용할수 있는 메모리 형태로 만들어 주어야 한다.
$ mkswap /swapfile
그러면 Swap 메모리가 만들어진다.
Setting up swapspace version 1, size = 3145724 KiB
no label, UUID=cb9b919d-dfa9-406f-99e3-9717b7c96b514. 이제 만들어진 Swap 파일을 Swap 메모리 영역에 올려주면 된다.
$ swapon /swapfile
5. free명령어로 확인하면 가상메모리 (Swap)영역이 증가한 것을 확인 할 수있다.
total used free shared buffers cached
Mem: 738540 731124 7416 0 5828 371416
-/+ buffers/cache:353880 384660
Swap: 3145724 0 3145724No-SQL (Not only SQL) 시작
1998년 카를로 스트로찌(Carlo Strozzi)라는 엔지니어가 공개한 표준 SQL 인터페이스를 채용하지 않은 자신의 경량 Open Source 관계형 데이터베이스를 No-SQL이라고 명명한데서 유래되었다고 한며, 이후 2009년에는 요한 오스칼손(Johan Oskarsson)이라는 엔지니어가 Open Source기반의 분산 데이터베이스 관련 행사를 준비하면서 No-SQL이라는 용어를 널리 사용하기 시작하였다고 한다.
초기 No-SQL은 기존의 관계형 데이터베이스 시스템의 주요 특성을 보장하는 ACID(Atomicity, Consistency, Isolation, Durability) 특성을 제공하지 않았다. 때문에 No-SQL이 등장한 이후에도 시장에서는 관계형 데이터베이스가 데이터를 처리하는데 가장 최적의 시스템으로 받아들여졌다.
기업 데이터의 정확한 처리가 필수적이기 때문에 기업 시스템에서는 현재도 관계형 데이터베이스를 훨씬 많이 사용한다. 무엇보다도 표준 SQL 이라고 하는 데이터를 처리하는 언어의 편이성 때문에 No-SQL 등 다른 데이터베이스 시스템들은 많이 활용 되지 않았다.
2000년 후반으로 넘어오면서 인터넷이 활성화되고, 소셜네트워크 서비스(SNS)등이 등장하면서 관계형 데이터 또는 정형데이터가 아닌 데이터, 즉 비정형데이터라는 것을 보다 쉽게 담아서 저장하고 처리할 수 있는 구조를 가진 데이터 베이스들이 관심을 받게 되었고, 해당 기술이 점점 더 발전하게 되면서, No-SQL 데이터베이스가 각광을 받기 시작했다.
기존의 관계형 데이터베이스 보다 더 융통성 있는 데이터 모델이 요구되며, 데이터의 저장 및 검색을 위한 특화된 매커니즘이 필요 해지기 시작했고, No-SQL은 단순 검색 및 추가 작업에 있어서 매우 최적화된 키 값 저장 기법을 사용하여, 응답속도나, 처리 효율 등에 있어서 매우 뛰어난 성능을 내주면서, 비정형 데이터를 다루는 SNS, 머신러닝 등 AI 산업에 많이 사용되기 시작했다.
SQL VS No-SQL
| SQL | VS | No-SQL |
| 정해진 규격에 의한 정적 정의 | Schema | 정해진 규격 없음. 동적 정의 |
| 가능 | Data Join | 불가능 |
| 표준 | SQL | 비표준 |
| 보장 | Transcation | 미보장 |
| 어려움 | Distribute | 쉬움 |
No-SQL 종류
1. Key-Value DB
2. Wide Column DB
3. Document(-oriented) DB
4. Graph DB
검색엔진에서 많이 사용하는 방법인데, 검색엔진은 사이트의 모든 페이지를 검색 로봇이 검색해서 문서내의 단어들을 색인하여 URL에 맵핑해서 저장해놓는다.
| Key | Value |
| bcho.tistory.com/nosql | nosql, cassandra, riak |
| bcho.tistory.com/cloud | amazon, azure, google |
| facebook.com/group/serverside | amazon, google, riak |
| highscalability.com/bigdata | nosql, riak |
| http://www.basho.com/riak | riak |
검색은 단어를 키로 검색이 되기 때문에, 위의 테이블 구조에서는 value에 검색 키워드들이 들어가 있기 때문에, 효과적인 검색을 할 수 없다.이 검색 키워드를 키로 해서 URL을 value로 하는 테이블을 다시 만들어 보면, 아래와 같은 식으로 표현되고, 검색 키워드로 검색을 하면 빠르게, 검색 키워드를 가지고 있는 URL을 찾아낼 수 있다.
| Key | Value |
| riak | bcho.tistory.com/nosql facebook.com/group/serverside highscalability.com/bigdata http://www.basho.com/riak |
| nosql | bcho.tistory.com/nosql highscalability.com/bigdata |
이렇게 value의 내용을 key로 하고, key의 내용을 반대로 value로 하는 패턴을 inverted search index라고 한다.
JSON Object를 화면에 바로 보여주어야 할 때, 그냥 바로 출력을 하면 한줄로 길게 표현이 되기 때문에, 가독성이 떨어진다. 하지만 다음과 같이 하면 들여쓰기를 하여 JSON Object를 보기 좋게 프린트 할 수 있다.
1. Html
<pre><code class=JsonResult></code></pre>
2. Javascript
var jsonObject = [{name: "Gil-Dong", Age: 20, Birthday: new Date("2001-01-01")},{name: "Young-Hee", Age: 25, Birthday: null}];
$('.JsonResult').html(JSON.stringify(jsonObject, null, 3));
3.Result
[
{
"name": "Gil-Dong",
"Age": 20,
"Birthday": "2001-01-01T00:00:00.000Z"
},
{
"name": "Young-Hee",
"Age": 25,
"Birthday": null
}
]다음과 같이 하면 html table에 있는 리스트 형태의 데이터들을 JSON Object 형태로 만들어 사용할 수 있다.
var List = [];
var headers = $("table th");
$('table .tableRows').each(function (i, row) {
List[i] = {};
$(row).find('td').each(function (j, cell) {
List[i][$(headers[j]).text()] = $(cell).find('input').val();
});
});
-유의사항-
이 코드는 최적화하여 만들어진 것은 아니고 단순히 Jquery 스크립트로만 위문제를 해결한 것이기 때문에, 더 좋은 최적화된 오픈 소스 혹은 라이브러리가 있다면 그것을 사용하는 것을 권장한다.
오픈소스 라이선스는 굉장히 많이 존재 하지만 분류를 해보면 크게 3가지 계열로 나눌 수 있다.
3가지 계열에 대한 라이선스 구분은 다음과 같다.
1. Permissive
오픈소스의 최소한의 성격만을 보장하는 라이선스로, 누구나 개작 할 수 있고, 수정한 것을 제한 없이 배포할 수 있다. 또한, 코드 공개의 의무가 없기 때문에 재배포를 한다고 하여서 프로그램 코드를 공개 할 필요가 없다. 이러한 이유 때문에 상용 소프트웨어를 만드는 회사에서 Permissive 계열의 라이선스를 많이 선택 한다. Permissive 계열 라이선스의 대표적인 예로는 BSD, MIT, Apache 2.0 등이 있다.
2. Weakly Protective
초기 Strongly Protective 계열의 라이선스 조항에 대한 불만으로 인해서 조금 완화한 라이선스이다. 오픈소를 가져다 사용할때, 수정하지 않고 동적 라이브러리 형태로 분리되어 동작한다면 프로그램 코드를 공개할 필요가 없다. Weakly Protective 계열 라이선스의 대표적인 예로는 LGPL과 MPL 등이 있다.
3. Strongly Protective(Network Protective)
자유 소프트웨어 재단(FSF)에서 만든 대표적인 라이선스 체계로 굉장히 강력한 오픈소스 정책이 담겨져있다. 오픈소스를 사용할때에 개작없이 있는 그대로 독립적으로 사용한다면 공개의 의무가 없지만, 조금 이라도 수정하거나 정적/동적으로 참조하여 사용하는 경우 모두 프로그램 코드를 공개해야 한다. 특히나, Network Protective 계열의 라이선스는 클라우드 SaaS 서비스의 특성에도 Stongly Protective를 적용하기 위해서 나온 것으로 배포되지 않고 SaaS 형태로 서비스를 하더라도 프로그램 코드를 공개해야하는 의무가 있다. Strongly Protective(Network Protective) 계열 라이선스의 대표적인 예로는 GPL2, GPL3와 AGPL 등이 있다.
라이선스 계열 분류는 전문에 나타난 내용들의 제약사항의 강도에 따라서 분류를 한 것다. 개발할 제품의 비즈니스 전략에 따라 대략적인 라이선스 정책 방향을 선택 할 수 있을 것이라고 생각한다.
THE NEWTH 