If your OneNote complains that your notebook can't be shared because MS has some problem.......

This is rare condition, but sometimes OneNote for Windows 10 complains that your notebook can't be shared because there's something from Microsoft side. And you have no idea where and why.

In this case(as I experienced), log in to OneDrive web page(https://onedrive.live.com). And I'm sure that MS will ask you to prove you're not a bot(but why?). I proved myself by confirming a PIN number vis SMS.

Hey Microsoft, though my wife complains that I'm like an A.I.(artificial intelligence)-installed robot, I'm more human than a bot. :P

If deleted OneNote notebook still shows in your OneNote for Windows 10 (UWP) application......

Yes. I'm sure so many people experienced it. You surely deleted your notebook from OneNote for Windows and OneDrive, but if you click More Notebooks you'll see your deleted notebook is still on the list. What's more, if you try to open them, it says OneNote failed to open them. What the hell?
So called Phantom Notebook by someone, this is quite a nuisance. And I'm sure you may also have seen a lot of "solutions" when you have MS Office 2016 - clear Recent in OneNote 2016. Well, the problem arises when you don't have MS Office. And everyone will agree that it's quite too much to subscribe to Office 365 to remove the list......

But did you know that there's one more location where you can access and clear that Recent? You can't find it in OneDrive. It's on Office.com.

Oh yeah. https://www.office.com/ ← Log in here.

If you visit the page and log in, you'll see the list of recently opened documents, and you can also see your deleted OneNote notebooks. You can safely remove those 'phantoms' by clicking ... icon in the middle of the list; after that, go to OneNote Online or OneNote for Windows 10, you can see your list is finally clean now. :)

Hope this helps if you're uncomfortable with it.

OneNote for Windows 10 (UWP)에서 지운 노트북이 계속 보인다면......

예. 아마 많은 분들이 경험하셨을겁니다. 분명히 OneNote for Windows와 OneDrive에서 노트북을 지웠는데 OneNote의 전자 필기장 더 보기를 선택하면 지워진 노트북이 목록에 그대로 떠있는 경우가 있습니다. 해외에서는 Phantom Notebook이라는 표현을 쓰기도 하는 것 같더군요.

뭐, OneNote 2016을 쓰고 있다면 Recent를 지워서 해결할 수 있는데, 문제는 OneNote 2016을 쓰지 않는 경우입니다. 목록 지우자고 Office 365를 구매하는건 좀 오버인 것 같고......

그런데 이 최근 문서 목록을 지울 수 있는 위치가 한군데 더 있습니다. OneDrive에서는 찾을 수 없고요, Office.com으로 로그인하면 바로 나옵니다(-_-).

예. https://www.office.com/ ← 바로 여깁니다.

여기 가시면 여태까지 열었던 문서들의 목록이 나오고, 그중에 지워진 OneNote 노트북도 보이실겁니다. 중간의 ... 아이콘을 클릭하시면 바로 해당 목록을 삭제하실 수 있고, 삭제하신 뒤 OneNote Online이나 OneNote for Windows 10을 열어서 확인해보시면 지워진 노트북이 보이지 않는 것을 확인하실 수 있으실겁니다.

혹시 이것때문에 많이 불편하신 분이 계셨다면 도움이 되셨길 바랍니다.

Choosing a database

Nowadays I'm developing a new product and I'm stuck with choosing the "right" database.
 Well, today we have a wide variety of choices including NoSQL, but too many choices makes me more difficult on selection. I have to consider more things, and I have no idea on how the users will use the product. In my situation I concluded NoSQL is not the way so I'm considering three among SQL engines, but all the candidates bite me on some area.

1. ​SQLite: unlike what others think, SQLite has no problems at all on using in production environment. It's stable and FAST. Especially, it's so "lightning" fast that the spiral booster is always turned on(c.f. Cyber Formula). In almost all cases it overwhelms the others. However, it doesn't support concurrent write. To do it, I have to make a wrapper to do it for the database. OTL
2. PostgreSQL: magnificent. I dare to say it's the best in the world of open source. Though it is based on SQL(I know it's ORDB, but anyway) yet supports NoSQL too. The problem is it's damn sloooooooooooooow like snail and consumes a lot of resources. I can tune it to make it faster but still it lacks some speed.
3. MariaDB: Fast. I see the speed on most of SQL commands I use. If I use Aria with some setup, in some (limited) conditions it can be faster than SQLite. However, it sometimes hits my back hard. Pretty hard. Even just now, I found a 2-second query suddenly took 11 minutes. And now it takes 42 seconds. Hey you seal?

From the viewpoint of a developer, speed is important, but the more important is whether it's foreseeable or not. If it's slow I can tune it hard, and if it's still slow I can make the application to do another thing concurrently when doing slow stuff, but if the performance is that random, simply I can't use it.

Well, I think I have to ride the elephant again and drop my belief to the Holy Mother.

(or making with the database for missiles......)

데이터베이스 선택의 문제

작금 제품을 개발하면서 가장 커다란 과제중 하나가 데이터베이스 선택입니다.

뭐, 요즘은 NoSQL 포함해서 다양한 상황에 부합하는 여러 제품들이 나와있습니다만, 그렇기 때문에 더 선택이 어려워지기도 합니다. 고려해야 할 사항도 많을 뿐더러, 사용자가 실제로 이 제품을 어떻게 쓸지도 솔직히 예측이 쉽지 않기 때문에 더 그렇습니다. 저같은 경우는 NoSQL은 아직 아닌 것 같아서 SQL들 중에 고르고 있는데...... 이게 난감하네요. 현재 세 가지를 고려하고 있는데, 셋 다 뭔가 하나씩 부족합니다.

1. ​SQLite: 많은 사람들의 생각과는 다르게, SQLite를 제품에 적용하는데는 아무런 문제가 없습니다. 안정적이고, 빠릅니다. 속력만 놓고 보면 스파이럴 부스터를 항시 켜놓은 느낌입니다. 모든 경우에서 밑의 두 개를 말 그대로 '발라버립니다.' 그런데 concurrency 지원이 안됩니다. 굳이 하려면 직접 만들어야 해요. OTL
2. PostgreSQL: 오픈소스계 최강입니다. SQL이면서 NoSQL 기능까지 같이 들어있는...... 단점이라면 (특히 쓰기가) 거북이처럼 느리고, 자원 소모가 상당하다는 겁니다. 튜닝을 좀 하면 빨라지긴 하는데, 그래도 제가 원하는 수준까지 끌어내기에는 부족합니다. OTL
3. MariaDB: 빠릅니다. 주로 사용하는 구문이 빠르게 움직입니다. Storage engine을 Aria로 놓고 설정을 좀 해놓으면 특정 상황에서는 SQLite보다 더 빨라지기도 합니다(......). 단점이라면 가끔 예측 불가능한 행동을 한다는 거죠. 방금전에도 2초면 끝나던 query 하나가 갑자기 11분 넘게 뻘뻘대더니만 지금은 인풋 한번 수행시간이 평균 42초가 되었습니다(......OTL).

무언가를 만드는 사람의 입장에서는 속도도 중요하지만 더 중요한건 예측 가능성인 것 같습니다. 만일 뭔가 느리다면 속도를 최대한 끌어올리고, 그래도 안되면 느린 작업을 하는 동안에 다른 작업을 수행하게 만들면 되는데, 작업이 저렇게 예측 불가능하게 들쭉날쭉하게 움직이면 답이 안 나오더군요.

뭐, 아무래도 믿었던 성모님으로의 신앙(?)을 버리고 다시 코끼리 등 위에 올라타야 될 것 같습니다.

(아니면 미사일 DB로 뚝딱뚝딱 만들거나......)

DB insertion speed test

To be used in my work, I tested which database inserts the records the fastest. Well, actually it was not much - I just created a table with integer(PK)/timestamp/integer and inserted 1 million records with only PK changing.

Benchmark environment is as follows:

• Dell Inspiron 7373/i5 8th generation
• Windows 10 Home
• Target database(all 32bits)
• PostgreSQL 10.6: used libpq
• FIrebird 3.0.3: used OO API (C++)
• SQLite3: #include <sqlite3.h> // ...... :P

And here comes the results and some remarks. I hope it would help visitors.
(I'm not that much good enough to make something open sourced, so this is the best I can offer to the community...... ;) )

• Insertion speed
• 1: SQLite, in-memory database: 2 seconds
• 2: PostgreSQL, COPY: 5 seconds
• 3: PostgreSQL, bulk insert: 7 seconds
• 4: Firebird, bulk insert: 10 seconds
• 5: SQLite, save to file: 56 seconds
• Disk I/O
• Thanks to Windows kernel, if the system receives too many small I/Os, it burdens disk too much, making it to the bottleneck
• When using SQLite to save the result to disk where bulk insertion is impossible, disk I/O hit 100%
• In Firebird, bulk insertion is implemented via PSQL, where you send a number of records and the each INSERT line in PSQL sequentially inserts the records; still it burdens the disk I/O very high(around 50%), though lower than SQLite
• In Firebird, set the page size to at least 8192 to lessen disk I/O burdens
• Bulk insertion
• We can speed up the insertion using bulk insertion, but we have some speed bottleneck, regardless of disk I/O.
• Firebird: 10 records at once, regardless of page size
• Using stored procedure
• PostgreSQL: 40 records show the maximum performance
• PostgreSQL
• COPY(source: CSV) is incredibly fast. Even the official documentation recommends COPY in bulk insertion
• In libpq, the speed is around same whether you send the records in either text or binary
• Miscellany
• It's far faster to use the official interface directly rather than using any wrapper. When testing Firebird at first, with SOCI it took 59 seconds, while after applying the same logic to Firebird OO API directly the time taken is shrunk to only 20-something seconds.

That's all. Please let me know if you have any questions or comments. =_=/

DB insertion 속도 테스트

업무상 필요로 인해 어느 DB가 record insertion을 제일 빠르게 하는지를 테스트하게 되었습니다. 뭐 대단한걸 한건 아니고, integer(PK)/timestamp/integer로 구성된 테이블에서 PK값만 바꾸고 나머지는 고정값으로 해서 1백만개 레코드를 일괄 등록하는 프로그램을 만들어 돌려봤습니다.

대상 환경은 이렇습니다

• Dell Inspiron 7373/i5 8세대 모델
• Windows 10 Home
• 대상 DB(모두 32비트 모델)
• PostgreSQL 10.6: libpq 사용
• FIrebird 3.0.3: OO API (C++) 사용
• SQLite3: #include <sqlite3.h> // ...... :P

결과 및 시사점을 정리합니다. 도움이 되셨으면 합니다.
(아직 뭔가를 만들어 open source로 만들어 내놓을 정도의 실력이 되지는 않으니 이런거라도......)

• Insertion 속도
• 1위: SQLite, in-memory database: 2초
• 2위: PostgreSQL, COPY: 5초
• 3위: PostgreSQL, bulk insert: 7초
• 4위: Firebird, bulk insert: 10초
• 5위: SQLite, 파일에 저장: 56초
• Disk I/O 관련
• Windows 커널 특성상 small I/O가 많아지면 disk에 부담이 너무 많이 가 bottleneck이 됨
• Bulk insert가 불가능한 SQLite 파일 저장 조건에서 disk I/O가 100%가 됨
• Firebird의 경우, PSQL을 사용하여 bulk insert를 구현하는 형태로, 다수의 레코드를 한번에 받아 디스크에 개별 INSERT 명령어를 사용하여 순차적으로 쓰는 형태로 구현되므로, SQLite급까지는 아니더라도 disk I/O가 높게 일어남(disk I/O 50%)
• Firebird의 경우 page size를 최소 8192이상으로 가져가는 것이 disk I/O 부하 감소에 도움이 됨
• Bulk insertion 관련
• Bulk insertion을 이용하여 insertion 속도를 올릴 수 있으나, 일정 수준 이상을 넘어서면 속도가 더이상 올라가지 않음. 이는 disk I/O와는 별개임
• Firebird: 10개 수준에서 최고속력을 보임(page size와 상관없음)
• Sotred procedure 
• PostgreSQL: 40개 수준에서 최고속력을 보임
• PostgreSQL 관련
• COPY(원본: CSV 기반)가 규격외로 빠른 속력을 보임. 실제로 공식 메뉴얼에서도 bulk insertion에서는 COPY를 추천함
• libpq에서 insertion 데이터를 보낼때 데이터를 text와 binary 중 어느 형태로 보내도 소요 시간은 동일함
• 기타
• 각 DB에서 제공하는 직접 연결 인터페이스를 사용하는 것이 wrapper를 사용하는 것보다 훨씬 빠름. Firebird로 최초 테스트시, SOCI 적용시 59초가 소요되었으나 Firebird OO API로 동일 로직 구현시 20초대에서 완료됨

이정도입니다. 혹시 궁금하신 점이 있으시면 문의 주세요. =_=/