世界的日曜WEBプログラマー日記 -22ページ目

世界的日曜WEBプログラマー日記

一年後に世界的なWEBサービスを運営するにはどうすればいいのか書いていく(予定)


PDFをPILのイメージに変換する方法について説明する。
PDFをBMPなどに変更するにはconvertコマンドが便利で、
$ convert -density 600x600 a.pdf a.bmp
のようにして変更できる。
これをPythonを使って画像として触るためには実現するにはpythonのImageMagickのバインディングPythonMagicとPython Imaging Library(PIL)を用いる。
PDFからPILに変換する方法は意外とどこにも載っていなかったので苦労した。

以下にコードを示す。
import Image, PythonMagick, numpy
def PDF2PIL( pdfpath ):
img = PythonMagick.Image()
img.density( '300' )
img.read( pdfpath.encode('utf-8') )
blb = PythonMagick.Blob()
img.write( blb, 'GRAY' )
data = blb.data
pilimg = Image.fromstring('L', (img.columns(), img.rows()), (numpy.fromstring(data, numpy.uint16) >> 8).astype(numpy.uint8).tostring() )
return pilimg


ポイントはimg.writeでGRAYを選択するところ。
ここではPNGやBMPなども指定できる。オプションに関してはImageMagickと同じである。
サポートフォーマット --> http://www.indopedia.org/index.php?title=PythonMagick

戻り値が16ビットで戻ってくるので8ビットに変換しなくてはならない.
16ビットから8ビットへの変換はnumpyを用いる。そしてPILのfromstrigで読み込む。

意外と苦労した。

株式会社OctOpt
コンピューターサイエンス会社OctOptの技術公式ブログ
等々力 康弘
@rocky_house

Django使ってんだから昔みたいにimport MySQLdbして、とかヘボイ事してんじゃねぇぜ
http://www.djangobook.com/en/2.0/chapter16/
みたいな記事を見つけた。じゃあ、Djangoラッパーを使おう!と思ったけど中々うまくいかない。

解決策を見つけたので以下に示します。
こいつを使えばDjangoラッパーを介してガシガシモデルをいぢれます。あー苦労した。

今webappsというDjangoのプロジェクトを/home/ytodoroki/dynaptico/maishoku/の下に作成したとします。
プロジェクトの中にocrというアプリを作成しました。
そしてwebapps/ocr/models.pyを編集してDownloadというモデルを作ったとします。

 $ django-admin startproject mysite
$ cd mysite
$ django-admin startapp ocr
$ emacs models.py # Downloadを作成(名前は任意。以下の説明のため)

そのモデルに好きなところからアクセスしたり、いぢったりするにはスクリプトの最初で以下のように色々なモジュールをimportする必要があります。

import sys, os
sys.path.append( '/home/ytodoroki/dynaptico/maishoku/webapps/' )
os.environ['DJANGO_SETTINGS_MODULE'] = 'webapps.settings'
import settings
from django.core import management
management.setup_environ( settings )
from ocr.models import Download


ミソはos.environをきちんと定義し、そのあとでdjango.coreのmanagementを使って環境をきちんと読み込むことである。

株式会社OctOpt
コンピューターサイエンス会社OctOptの技術公式ブログ
等々力 康弘
@rocky_house

NoSQLについて
NoSQLは「Not Only SQL]でリレーショナルなデータベースだけじゃねぇぜという意味で、SQLを否定しているわけではありません。
NoSQLの代表的な3つ以下に挙げてみます。
・Cassandra( facebook )
・MongoDB
・HBase( GoogleのBigtableライク )
上記三つはコンピュータに携わる方なら必ず知っておきましょう。

NoSQLを理解する上で避けて通れないのはCAP理論です。CAP理論の[CAP]とは
一貫性(C)、可視性(A)、分散性(P)
を表しています。「一貫性」とはデータが一貫性していることを表し、可視性とはどんなときもアクセス可能であること、分散性とは分散して処理が出来ることを表しています。
データベースにはその特性をみてC,A,P、或いはそれらの組み合わせ(CA, APなど)の属性を割り当てることが可能です。ただし、CAPを3つ満たすDBはこの世に存在しません。

世にあるDBがどのような属性を持っているか見てみます。
例えばMySQLなどのRDBMSは一貫性と可視性を備えています。CとA属性があるといえます。しかし分散したサーバでMySQLを管理することはとても難しいものです。MySQLは上記で言うP属性がありません。

Cassandra, MongoDB, HBaseは分散サーバ向きです。すべてにP属性が付いています。
データが非常に多くなってきた近年、データを捌ききるためには分散して処理できる機構が必要です。
P属性がつくデータベースが求められてきています。
昨今ではNoSQLが流行っているといわれますが、「分散性があるサーバが流行っている」と言ったほうが正しいです。分散サーバはNoSQLであることが多く、結果としてNoSQLが流行ってきているのです。

さて、CAP理論にもどりますが、CAPのうち同時に3つが満たされない事について簡単に説明します。
HbaseとMogoDBは一貫性Cがとられています。つまりMySQLのようにいつでも正確なデータを返します。しかし分散サーバです。分散ということはデータを保持したサーバが一個落ちればその中にあるデータは見ることはできません。つまりA属性である可視性が犠牲になっています。(Aを犠牲にしてPとCを取りました。)

Cassandraは一貫性を無視しました。その代わり中にデータのコピーを複数持つことで分散サーバのうち、一台が落ちても他のサーバを経由してデータを覗ける仕組みを設けています。つまりAccess性は失いません。その代わりですが、内部でのデータコピーあるということで、これが一貫しているとは限らなくなります。Cassandraは一貫性であるC属性を無視し、そのかわりA属性を重視したのです。Cを犠牲にしてAとPを取ったのです。

MySQLは分散性はなく、そのかわりAccess性と一貫性があります。

このようにC、A、Pはみっつ同時にはなりえないのです。

CA, CP, APのモデルを使えばいいかについてはサーバの種類で使い分けるといいでしょう。
例えばデータ量がそんなに多くなければ分散サーバの意味は余り無いためP属性を無視できます。
C属性とA属性を満たすサーバといえばMySQLなどのリレーショナルなデータベースです。ただし、MySQLはカラム追加が面倒です。ここで、MongoDBがキラリと光ってきます。

MongoDBは分散化できますが、分散化しなくても構いません。分散化しなければP属性がなくなります。
そして分散する必要は無くなったためA属性が現れます。MongoDBは一貫性(C)のあるDBですのでAC属性となり、結果MySQLと同じ属性になります。そしてMongoDBはスキーマレス(カラムの追加が自由自在)です。MongoDBが流行っているのは、スキーマレスでMySQLと同じ属性を持つことができるからでしょう。
なお、MongoDBはShardingを用いることで分散データベースを実現します。詳しくは本家のドキュメントをご覧ください。いつか紹介しようと思います。

蛇足ですがCassandra、Hbaseは列指向、MongoDBドキュメント指向と言われています。
こちらも詳しくは別の機会に説明します。

株式会社OctOpt
コンピューターサイエンス会社OctOptの技術公式ブログ
等々力 康弘
@rocky_house