[firebase-br] Crescimento do banco, ate onde?

Fernando Reis Guimarães fernandobhz em gmail.com
Sáb Set 30 16:09:32 -03 2006


Bom e quanto a velocidade?

Exemplo:

Olha não sei o melhor banco de dados para velocidade, mas digamos que seja
oracle.

Qual seria mais rápido Firebird ou Oracle, para selects inserts e updates em
uma tabela com 6 milhões de registros mensais e com 360 milhões de registros
antigos. ( Situação da CEMIG - Compania Energétia de Minas Gerais )
Considerando 10.000 mil usuários acessando-as constantemente de 8h as 17.

Desculpa se to falando besteira, mas um banco de dados desse porte deve ter
vários servidores, divisões algo assim.

Mas a perguta é, isso é viável no Firebird tanto quanto ao Oracle e se sim
como fica a velocidade?

Grato.


2006/9/30, Eduardo Jedliczka (TeamFB) <jedyfb em gmail.com>:
>
> bom, se sua preocupação é o tamanho da base, há algumas considerações a
> fazer:
>
> qualquer SGDB possui a limitação do tamanho do sistema de arquivos, pois o
> SGDB implementa arquivos. Exceto casos em que o SGDB cria a sua própria
> partição no disco rígido. (algo como o antigo volume da novell netware)
>
> Porém, a forma como esta limitação é apresentada para o usuário difere, e
> às
> vezes até elimina esta dificuldade.
>
> Por exemplo:
>
> o MySql na versão 3, criava pelo menos três arquivos para cada tabela do
> banco de dados, (imagina uma única tabela sem índices com "2 GB reais" de
> dados em mysql)
>
> o Oracle adota o sistema de Schema, TableSpace, etc.. onde a
> responsabilidade de administrar tabelas e volumes é toda jogada para o
> SYSDBA.
>
> o FireBird usa um conceito diferente, onde o SYSDBA tem pouquíssimo
> trabalho
> (DBA Oracle acham isto muito ruim, pois causa uma drástica redução de
> salário à profissão). Sendo assim, ele permite que uma base de dados possa
> estar armazenada em um um mais arquivos físicos, pois o banco utiliza o
> conceito de páginas (PageSize). Se você dividir a sua base de dados em
> dois
> ou mais arquivos, estes arquivos continuarão submetidos às regras do
> sistema
> de arquivos do SO, mas serão vistos de forma transparente para quem
> utiliza
> o banco de dados.
>
> Ou seja, se você dividir sua base de 100MB em 100 arquivos de 1MB, o
> funcioanamento será exatamente o mesmo de quando ele tinha um único
> arquivo
> de 1MB.
>
> ======================
> Eduardo Jedliczka
> Membro do TeamFB - FireBase
> Apucarana - PR
> ======================
> "Posso não concordar com nada do que dizes.
> Mas defenderei até a morte o seu direito de dizê-lo"
> (Voltaire 1694-1778)
> ----- Original Message -----
> From: "Wainer" <wainer em megasinal.com.br>
> To: "FireBase" <lista em firebase.com.br>
> Sent: Saturday, September 30, 2006 1:31 PM
> Subject: Re: [firebase-br] Crescimento do banco, ate onde?
>
>
> Ba Tarde
>
>    Nao imaginava tantas consideracoes, mas ficaram ainda algumas duvidas
> do
> email inicial
>
> 1 - o SO nao limita todos os banco quanto ao tamanho?
>
> 2 - caso use a agragacao de mais de um arquivo ao banco como fica um
> select
> que tenha dados em todos estes arquivos
>
> 3 - Como nosso amigo afirmou que o Firebird serve para 95% dos casos dele
> ,
> ou seja as limitacoes que foram mencionadas
>       nao ficariam para aqueles casos que raramente se usa e ainda, o que
> temos no firebird ja nao atenderia bem para a  grande maioria dos usuarios
> ?
>
> obrigado
>
> Wainer
> 16-9999-6697
>
> Wisa soft
> 16-3721-7187
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para editar sua configuração na lista, use o endereço
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para editar sua configuração na lista, use o endereço
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>



-- 
Atenciosamente;
Fernando.



Mais detalhes sobre a lista de discussão lista