Je veux une sélection aléatoire de lignes dans PostgreSQL, j'ai essayé ceci:

select * from table where random() < 0.01;

Mais certains autres recommandent ceci:

select * from table order by random() limit 1000;

J'ai une très grande table avec 500 millions de lignes, je veux que ce soit rapide.

Quelle approche est la meilleure? Quelles sont les différences? Quelle est la meilleure façon de sélectionner des lignes aléatoires?

Compte tenu de vos spécifications (plus d'informations supplémentaires dans les commentaires),

• Vous avez une colonne d'ID numérique (nombres entiers) avec seulement quelques (ou modérément peu) lacunes.
• Évidemment, aucune ou peu d'opérations d'écriture.
• Votre colonne ID doit être indexée! Une clé primaire sert bien.

La requête ci-dessous n'a pas besoin d'une analyse séquentielle de la grande table, seulement une analyse d'index.

Tout d'abord, obtenez des estimations pour la requête principale:

SELECT count(*) AS ct              -- optional
     , min(id)  AS min_id
     , max(id)  AS max_id
     , max(id) - min(id) AS id_span
FROM   big;

La seule partie éventuellement chère est la count(*)(pour les tables énormes). Compte tenu des spécifications ci-dessus, vous n'en avez pas besoin. Une estimation fera très bien l'affaire, disponible presque gratuitement ( explication détaillée ici ):

SELECT reltuples AS ct FROM pg_class WHERE oid = 'schema_name.big'::regclass;

Tant qu'elle ctn'est pas beaucoup plus petite que id_span, la requête surpassera les autres approches.

WITH params AS (
    SELECT 1       AS min_id           -- minimum id <= current min id
         , 5100000 AS id_span          -- rounded up. (max_id - min_id + buffer)
    )
SELECT *
FROM  (
    SELECT p.min_id + trunc(random() * p.id_span)::integer AS id
    FROM   params p
          ,generate_series(1, 1100) g  -- 1000 + buffer
    GROUP  BY 1                        -- trim duplicates
    ) r
JOIN   big USING (id)
LIMIT  1000;                           -- trim surplus

• Générez des nombres aléatoires dans l' idespace. Vous avez "quelques lacunes", alors ajoutez 10% (assez pour couvrir facilement les blancs) au nombre de lignes à récupérer.

• Chacun idpeut être sélectionné plusieurs fois par hasard (bien que très peu probable avec un grand espace d'identification), alors regroupez les numéros générés (ou utilisez DISTINCT).

• Rejoignez le ids à la grande table. Cela devrait être très rapide avec l'index en place.

• Enfin, coupez les surplus idqui n'ont pas été mangés par les dupes et les lacunes. Chaque ligne a une chance tout à fait égale d'être sélectionnée.

Version courte

Vous pouvez simplifier cette requête. Le CTE dans la requête ci-dessus est uniquement à des fins éducatives:

SELECT *
FROM  (
    SELECT DISTINCT 1 + trunc(random() * 5100000)::integer AS id
    FROM   generate_series(1, 1100) g
    ) r
JOIN   big USING (id)
LIMIT  1000;

Affiner avec rCTE

Surtout si vous n'êtes pas sûr des écarts et des estimations.

WITH RECURSIVE random_pick AS (
   SELECT *
   FROM  (
      SELECT 1 + trunc(random() * 5100000)::int AS id
      FROM   generate_series(1, 1030)  -- 1000 + few percent - adapt to your needs
      LIMIT  1030                      -- hint for query planner
      ) r
   JOIN   big b USING (id)             -- eliminate miss

   UNION                               -- eliminate dupe
   SELECT b.*
   FROM  (
      SELECT 1 + trunc(random() * 5100000)::int AS id
      FROM   random_pick r             -- plus 3 percent - adapt to your needs
      LIMIT  999                       -- less than 1000, hint for query planner
      ) r
   JOIN   big b USING (id)             -- eliminate miss
   )
SELECT *
FROM   random_pick
LIMIT  1000;  -- actual limit

Nous pouvons travailler avec un surplus plus petit dans la requête de base. S'il y a trop de lacunes et que nous ne trouvons pas suffisamment de lignes dans la première itération, le rCTE continue à itérer avec le terme récursif. Nous avons encore besoin de relativement peu lacunes dans l'espace ID ou la récursivité peut se tarir avant que la limite soit atteinte - ou nous devons commencer avec un tampon suffisamment grand qui défie le but d'optimiser les performances.

Les doublons sont éliminés par le UNIONdans le rCTE.

L'extérieur LIMITfait arrêter le CTE dès que nous avons suffisamment de lignes.

Cette requête est soigneusement rédigée pour utiliser l'index disponible, générer des lignes réellement aléatoires et ne pas s'arrêter jusqu'à ce que nous atteignions la limite (à moins que la récursivité ne sèche). Il y a un certain nombre d'écueils ici si vous voulez le réécrire.

Envelopper dans la fonction

Pour une utilisation répétée avec des paramètres variables:

CREATE OR REPLACE FUNCTION f_random_sample(_limit int = 1000, _gaps real = 1.03)
  RETURNS SETOF big AS
$func$
DECLARE
   _surplus  int := _limit * _gaps;
   _estimate int := (           -- get current estimate from system
      SELECT c.reltuples * _gaps
      FROM   pg_class c
      WHERE  c.oid = 'big'::regclass);
BEGIN

   RETURN QUERY
   WITH RECURSIVE random_pick AS (
      SELECT *
      FROM  (
         SELECT 1 + trunc(random() * _estimate)::int
         FROM   generate_series(1, _surplus) g
         LIMIT  _surplus           -- hint for query planner
         ) r (id)
      JOIN   big USING (id)        -- eliminate misses

      UNION                        -- eliminate dupes
      SELECT *
      FROM  (
         SELECT 1 + trunc(random() * _estimate)::int
         FROM   random_pick        -- just to make it recursive
         LIMIT  _limit             -- hint for query planner
         ) r (id)
      JOIN   big USING (id)        -- eliminate misses
   )
   SELECT *
   FROM   random_pick
   LIMIT  _limit;
END
$func$  LANGUAGE plpgsql VOLATILE ROWS 1000;

Appel:

SELECT * FROM f_random_sample();
SELECT * FROM f_random_sample(500, 1.05);

Vous pouvez même faire en sorte que ce générique fonctionne pour n'importe quelle table: prenez le nom de la colonne PK et de la table comme type polymorphe et utilisez EXECUTE... Mais cela dépasse le cadre de cette question. Voir:

• Refactoriser une fonction PL / pgSQL pour renvoyer la sortie de diverses requêtes SELECT

Alternative possible

SI vos besoins permettent des ensembles identiques pour les appels répétés (et nous parlons d'appels répétés), je considérerais une vue matérialisée . Exécutez la requête ci-dessus une fois et écrivez le résultat dans une table. Les utilisateurs obtiennent une sélection quasi aléatoire à la vitesse de l'éclair. Rafraîchissez votre choix aléatoire à intervalles ou événements de votre choix.

Postgres 9.5 présente TABLESAMPLE SYSTEM (n)

Où nest un pourcentage. Le manuel:

Les méthodes BERNOULLIet d' SYSTEMéchantillonnage acceptent chacune un seul argument qui est la fraction du tableau à échantillonner, exprimée en pourcentage entre 0 et 100 . Cet argument peut être n'importe realquelle expression évaluée.

Accentuation sur moi. C'est très rapide , mais le résultat n'est pas exactement aléatoire . Le manuel à nouveau:

La SYSTEMméthode est nettement plus rapide que la BERNOULLIméthode lorsque de petits pourcentages d'échantillonnage sont spécifiés, mais elle peut renvoyer un échantillon moins aléatoire du tableau en raison des effets de regroupement.

Le nombre de lignes renvoyées peut varier énormément. Pour notre exemple, pour obtenir environ 1000 lignes:

SELECT * FROM big TABLESAMPLE SYSTEM ((1000 * 100) / 5100000.0);

En relation:

• Un moyen rapide de découvrir le nombre de lignes d'une table dans PostgreSQL

Ou installez le module supplémentaire tsm_system_rows pour obtenir exactement le nombre de lignes demandées (s'il y en a assez) et autorisez la syntaxe la plus pratique:

SELECT * FROM big TABLESAMPLE SYSTEM_ROWS(1000);

Voir la réponse d' Evan pour plus de détails.

Mais ce n'est toujours pas exactement aléatoire.

Vous pouvez examiner et comparer le plan d'exécution des deux en utilisant

EXPLAIN select * from table where random() < 0.01;
EXPLAIN select * from table order by random() limit 1000;

Un test rapide sur un grand tableau ¹ montre que le ORDER BYpremier trie le tableau complet puis sélectionne les 1000 premiers éléments. Le tri d'une grande table lit non seulement cette table mais implique également la lecture et l'écriture de fichiers temporaires. La where random() < 0.1seule analyse le tableau complet une fois.

Pour les grandes tables, cela peut ne pas être ce que vous voulez, car même une analyse complète de la table peut prendre trop de temps.

Une troisième proposition serait

select * from table where random() < 0.01 limit 1000;

Celui-ci arrête l'analyse de la table dès que 1000 lignes ont été trouvées et revient donc plus tôt. Bien sûr, cela réduit un peu le caractère aléatoire, mais c'est peut-être suffisant dans votre cas.

Edit: Outre ces considérations, vous pouvez consulter les questions déjà posées à ce sujet. L'utilisation de la requête [postgresql] randomrenvoie plusieurs hits.

• sélection rapide et aléatoire des lignes dans Postgres
• Comment récupérer des lignes de données randomisées à partir d'une table postgreSQL?
• postgres: obtenir des entrées aléatoires de la table - trop lent

Et un article lié de depez décrivant plusieurs autres approches:

• http://www.depesz.com/index.php/2007/09/16/my-oughtts-on-getting-random-row/

¹ "grand" comme dans "le tableau complet ne rentrera pas dans la mémoire".

ordre postgresql par random (), sélectionnez les lignes dans un ordre aléatoire:

select your_columns from your_table ORDER BY random()

ordre postgresql par random () avec un distinct:

select * from 
  (select distinct your_columns from your_table) table_alias
ORDER BY random()

ordre postgresql par limite aléatoire d'une ligne:

select your_columns from your_table ORDER BY random() limit 1

À partir de PostgreSQL 9.5, il existe une nouvelle syntaxe dédiée à l'obtention d'éléments aléatoires à partir d'une table:

SELECT * FROM mytable TABLESAMPLE SYSTEM (5);

Cet exemple vous donnera 5% d'éléments de mytable.

Voir plus d'explications sur ce billet de blog: http://www.postgresql.org/docs/current/static/sql-select.html

Celui avec le ORDER BY va être le plus lent.

select * from table where random() < 0.01;va enregistrement par enregistrement, et décide de le filtrer au hasard ou non. Cela va être O(N)dû au fait qu'il n'a besoin de vérifier chaque enregistrement qu'une seule fois.

select * from table order by random() limit 1000;va trier la table entière, puis choisir les 1000 premiers. En dehors de toute magie vaudou dans les coulisses, l'ordre est O(N * log N).

L'inconvénient de celui- random() < 0.01ci est que vous obtiendrez un nombre variable d'enregistrements de sortie.

Remarque, il existe une meilleure façon de mélanger un ensemble de données que de trier par hasard: le Fisher-Yates Shuffle , qui s'exécute O(N). Cependant, implémenter le shuffle dans SQL semble être tout un défi.

Voici une décision qui fonctionne pour moi. Je suppose que c'est très simple à comprendre et à exécuter.

SELECT 
  field_1, 
  field_2, 
  field_2, 
  random() as ordering
FROM 
  big_table
WHERE 
  some_conditions
ORDER BY
  ordering 
LIMIT 1000;

select * from table order by random() limit 1000;

Si vous savez combien de lignes vous souhaitez, consultez tsm_system_rows.

tsm_system_rows

Le module fournit la méthode d'échantillonnage de table SYSTEM_ROWS, qui peut être utilisée dans la clause TABLESAMPLE d'une commande SELECT.

Cette méthode d'échantillonnage de table accepte un seul argument entier qui est le nombre maximal de lignes à lire. L'échantillon résultant contiendra toujours exactement autant de lignes, sauf si la table ne contient pas suffisamment de lignes, auquel cas la table entière est sélectionnée. Comme la méthode d'échantillonnage SYSTEM intégrée, SYSTEM_ROWS effectue un échantillonnage au niveau du bloc, de sorte que l'échantillon n'est pas complètement aléatoire mais peut être soumis à des effets de regroupement, en particulier si seul un petit nombre de lignes est demandé.

Installez d'abord l'extension

CREATE EXTENSION tsm_system_rows;

Ensuite, votre requête,

SELECT *
FROM table
TABLESAMPLE SYSTEM_ROWS(1000);

Si vous ne voulez qu'une seule ligne, vous pouvez utiliser un offsetdérivé calculé à partir de count.

select * from table_name limit 1
offset floor(random() * (select count(*) from table_name));

Une variante de la vue matérialisée «Alternative possible» décrite par Erwin Brandstetter est possible.

Supposons, par exemple, que vous ne souhaitiez pas de doublons dans les valeurs aléatoires renvoyées. Vous devrez donc définir une valeur booléenne sur la table primaire contenant votre ensemble de valeurs (non aléatoire).

En supposant que c'est la table d'entrée:

id_values  id  |   used
           ----+--------
           1   |   FALSE
           2   |   FALSE
           3   |   FALSE
           4   |   FALSE
           5   |   FALSE
           ...

Remplissez le ID_VALUEStableau selon vos besoins. Ensuite, comme décrit par Erwin, créez une vue matérialisée qui randomise la ID_VALUEStable une fois:

CREATE MATERIALIZED VIEW id_values_randomized AS
  SELECT id
  FROM id_values
  ORDER BY random();

Notez que la vue matérialisée ne contient pas la colonne utilisée, car celle-ci deviendra rapidement obsolète. La vue ne doit pas non plus contenir d'autres colonnes qui peuvent se trouverid_values tableau.

Afin d'obtenir (et « consommer ») des valeurs aléatoires, un UPDATE utiliser REVIENT sur id_values, la sélection id_valuesde id_values_randomizedavec une jointure, et appliquer les critères souhaités pour obtenir que des possibilités pertinentes. Par exemple:

UPDATE id_values
SET used = TRUE
WHERE id_values.id IN 
  (SELECT i.id
    FROM id_values_randomized r INNER JOIN id_values i ON i.id = r.id
    WHERE (NOT i.used)
    LIMIT 5)
RETURNING id;

Modifiez LIMITsi nécessaire - si vous n'avez besoin que d'une seule valeur aléatoire à la fois, passez LIMITà 1.

Avec les index appropriés id_values, je pense que la MISE À JOUR-RETOUR devrait s'exécuter très rapidement avec peu de charge. Il renvoie des valeurs aléatoires avec un aller-retour de base de données. Les critères pour les lignes "éligibles" peuvent être aussi complexes que requis. De nouvelles lignes peuvent être ajoutées à la id_valuestable à tout moment et elles deviendront accessibles à l'application dès que la vue matérialisée sera actualisée (ce qui peut probablement être exécuté à un moment hors pointe). La création et l'actualisation de la vue matérialisée seront lentes, mais elles ne doivent être exécutées que lorsque de nouveaux identifiants sont ajoutés à la id_valuestable.

Une leçon de mon expérience:

offset floor(random() * N) limit 1n'est pas plus rapide que order by random() limit 1.

Je pensais que l' offsetapproche serait plus rapide car elle devrait faire gagner du temps au tri dans Postgres. Il s'avère que ce n'était pas le cas.

Ajoutez une colonne appelée ravec type serial. Index r.

Supposons que nous ayons 200 000 lignes, nous allons générer un nombre aléatoire n, où 0 <n <<= 200 000.

Sélectionnez les lignes avec r > n, triez-lesASC et sélectionnez la plus petite.

Code:

select * from YOUR_TABLE 
where r > (
    select (
        select reltuples::bigint AS estimate
        from   pg_class
        where  oid = 'public.YOUR_TABLE'::regclass) * random()
    )
order by r asc limit(1);

Le code est explicite. La sous-requête au milieu est utilisée pour estimer rapidement le nombre de lignes de table à partir de https://stackoverflow.com/a/7945274/1271094 .

Au niveau de l'application, vous devez exécuter à nouveau l'instruction si n> le nombre de lignes ou vous devez sélectionner plusieurs lignes.

Je sais que je suis un peu en retard à la fête, mais je viens de trouver cet outil génial appelé pg_sample :

pg_sample - extraire un petit ensemble de données échantillon d'une base de données PostgreSQL plus grande tout en maintenant l'intégrité référentielle.

J'ai essayé cela avec une base de données de 350 millions de lignes et c'était vraiment rapide, je ne sais pas sur le caractère aléatoire .

./pg_sample --limit="small_table = *" --limit="large_table = 100000" -U postgres source_db | psql -U postgres target_db