|
개인적인 생각으로는 이번 row/table 에 대한 한계를 깨기위한 작업이 되고 나면 다음으로는 아마도 lo 에 대한 작업이 이루어지지 않을까 생각합니다. 사실 그런 측면에서 이번 7.1 작업이 가장 중요한 한 획이 될 것으로 생각합니다. 개인적인 생각으로는 아마도 8.0 으로 release 해도 전혀 손색이 없는 release 가 되지 않을까 생각중입니다. 그리고 위의 mailing list 를 보면 TB 급의 디비는 아마도 1G byte 단위의 파일로 나뉘어서 저장하는 방식을 선택하여 OS filesystem 에 independent 한 시스템을 만들기 위해 노력을 하는 모양이더군요.
하지만 현재로서는 large object 라는 것 자체가 사용하기 많이 힘든 것 만은 사실입니다.
>>김상기 님께서 쓰시길<<
::
:: >>정재익 님께서 쓰시길<<
::
:: :: I updated the maximum number of columns:
:: ::
:: :: Maximum size for a database? unlimited (60GB databases exist)
:: :: Maximum size for a table? 64 TB on all operating systems
:: :: Maximum size for a row? unlimited in 7.1 and later
:: :: Maximum size for a field? 1GB in 7.1 and later
:: :: Maximum number of rows in a table? unlimited
:: :: Maximum number of columns in a table? 250/1600 depending on column types
:: :: Maximum number of indexes on a table? unlimited
:: ::
::
:: 여기서 중요한 사실이 하나 빠졌는데요,
:: 이곳 게시판에서 예전에 썼듯이,
:: 하나의 서버에서 몇개의 database를 만들수 있느냐와,
:: 하나의 database에서 몇개의 table을 만들수 있느냐인데,
::
:: 이것이 PostgreSQL에서의 그 OS의 파일시스템에 의존적입니다.
:: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:: (오라클의 테이블스페이스 방식이 어쩌면 더 타당하다는 생각이 듭니다)
:: 그래서, FreeBSD에서는 하나의 디렉토리에서 만들어낼 수 있는
:: 하위 inode 수가 약 13,000개 정도더군요.
:: 즉, 하나의 서버에서 약 13,000개의 database를 만들수 있고,
:: 하나의 database에서 약 13,000개의 table을 만들수 있겠지요.
:: 테이블 문제에서는 예를들어서,
:: 그 테이블에서 large object를 사용하게 된다면,
:: 그리고, 그 large object가 약 7000개 정도 된다면,
:: inode full이 예상됩니다.
:: 왜냐하면, 이것이 하나의 디렉토리에 두개의 파일로 저장되기 때문입니다.
::
:: 이문제는 linux나 (커널 2.4.x 에서는 어떻게 되었는지 모르겠습니다),
:: OSF나, solaris나 별반 차이가 없더군요.
::
:: 또한 파일시스템 의존적인 MySQL에서도 이문제는 동일하더군요.
::
|
